@database Madhouse @author "Carsten Jahn" ## Amiga-Guide-Dokument f r den Madhouse-Screenblanker. ## Bitte AmigaGuide, MultiView oder einen Text-Anzeiger, der die .guide- ## Dateien anzeigen kann, benutzen. ## Solche Programme k nnen auf den Disketten der AmigaLibDisk-Serie ## ("Fish-Disks") und auf vielen anderen Serien und von Mailboxen bezogen ## werden. ## Die Anleitung kann zwar auch so gelesen werden, aber es ist bedeutend ## schwieriger... @node Main "Madhouse: Inhaltsseite" @{B}Hallo Freunde der modularen Screenblanker!@{UB} Vor Euch seht Ihr die Anleitung zu Madhouse - dem modularen Bildschirm- "Schoner" den Ihr m gen werdet. Das beste an Madhouse sind sicherlich die Blanker, denn hier haben wir uns wirklich M he gegeben um interessante Effekte zu erstellen. Doch auch das Hauptprogramm "Madhouse" welches die Module konfiguriert und aufruft, hat einiges zu bieten. Aber seht selbst. Um schnell die Blanker zu sehen bietet sich der Workshop an, der Euch bei den ersten Schritten begleitet. @{" Ein kleines Vorwort: Wer will das schon lesen? ",link preface} @{" Der Workshop: Schnell einsteigen. ",link workshop} @{" Die (Advanced) Options: Keine Festplatte? Pa wort? ",link adv_op} @{" Die Blankmodes: und alle Optionen... ",link blankers} @{" Das Error System: Spa mit Fehlern ",link errors} @{" Der Referenz-Teil: Wie ging das doch gleich? ",link reference} !! @{" F r Non-HD-User: Alles ber Buffering. ",link buffering} !! @{" Nicht nur f r C-Profis: Eigene Module hinzuf gen ",link programmers} @{" Registration, Sonstiges: der unvermeidliche - Anhang! ",link addon} @endnode @node preface "Ein Vorwort" Als er mit feuchten Fingern den klobigen Schalter bet tigte, sch ttelte es die Zahnr der der Festplatte locker hin und her. Der Aluminiumscheibensta- pel saugte sich an seine Vertikalachse, vier Schwenk rme zwengten sich j zwischen sie und entsandten Magnetfelder. Die Rotorbl tter neben den seriellen Stiftreihen zirkulierten um den L ftermotor. Ein tiefes R durchstr mte den Raum. Die gelbe Leuchtdiode begann aufgeregt zu blinken, mit einem Zittern w rgte der Monitor das erste Bild hervor. Ein pinkfar- bener, spitzer Pfeil nach Nord-West begann eifrig und hungrig Betonkl mit farbigen Bildern zu attackieren. Ein Beben ging ber die Tasten, die sich voller Furcht in der Mitte der Tastatur zusammenkauerten. Drei- hunderttausendmal wurde eine von ihnen von einem harten Fingerballen ge- troffen. Pl tzlich erlosch das Bild, der L fter verstummte, und die Lampe ging aus. Mist - Stromausfall. Und wieder nicht abgespeichert... -- Nach diesem kurzen Drama wollte ich aber eigentlich noch etwas sinn- volleres sagen. Als wenn die ersten zehn Zeilen auf der Inhalts-Seite nicht gereicht h tten, werde ich hier noch ein paar Anmerkungen loswerden, die sich sonst in keines der Kapitel so richtig einreihen lassen. @{FG Highlight}@{B}Ich, du, er-sie-es@{UB}@{FG Filltext} Die deutsche Sprachsyntax erm glicht die Verwendung einer H flichkeits- Form neben den normalen Anreden, die normalerweise benutzt wird wenn man es mit jemanden zu tun hat, den man nicht kennt. Also k nnte ich Sie den gesamten Text hinweg siezen. Andererseits werden viele Leser auch nicht gerade die ltesten sein, weshalb ich das "Sie" nicht verwenden werde. Das soll nat rlich nicht die 80-j hrigen User diskreminieren. Kurzum, ich habe mich f r Euch und Ihr entschlossen, was hier die gesamte Amiga-Fangemeinde anspricht. Wer sich damit nicht anfreunden kann, bitte sehr: Sehr geehrte Dame, sehr geehrter Herr! Wir gratulieren Ihnen recht herzlich zum Empfang der Madhouse-Distribution. Dieses Programmpaket wird Ihnen noch lange Freude bereiten, denn wir haben bei der Herstellung Wert auf ausgesuchte Materialien gelegt. Bitte lesen Sie diese Gebrauchsanweisung sorgf ltig durch. Da wir uns ja nun schon seit 80 Sekunden kennen, erlaube ich mir, Ihnen das Du anzubieten. Ich hei e Carsten, und du? (Stellvertretend f r Aicke chte ich hier anmerken, da Aicke Aicke hei @{FG Highlight}@{B}Englische Eindeutschung und deutsche Einenglischung@{UB}@{FG Filltext} Besonders die Einsteiger, die das "Commodore Benutzerhandbuch Workbench" gelesen haben (m glichst @{I}bevor@{UI} es auseinander fiel), wurden dort mit einer F lle von neudeutschen Begriffen konfrontiert, die sich in der englischen Sprache viel besser anh Von Bl ttersymbolen, Amiga-DOS Stapeldateien, Piktogrammen, Voreinstellern, Standardnamensmustern und nicht zuletzt Anmeldedateien ist hier die Rede. Ich bin aber noch mit Cyclegadgets, Scripts, Icons, Prefs, Patterns und Mountfiles aufgewachsen und finde z.B., da sich "Lokalisationsvorein- stellungsdialogfenster" etwas gedrungen anh rt... weshalb ich haupts lich Begriffe verwenden werde, wie man sie auch in Fachzeitschriften fin- @{FG Highlight}@{B}Hausgemachtes Sprachen-Wirrwar auf Commodore-Art: die locale.library@{UB}@{FG Filltext} Eine der tollsten (wenn auch eine der letzten...) Ideen, die Commodore noch vor dem Konkurs vollbrachte, war die locale.library. Zu ihr geh auch die ca. 50 Verzeichnisse und hunderte von Dateien, denn die locale.- library ist komplett modular aufgebaut. Falls also Mars-Kolonien entstehen sollten, oder ein Amiga an au erirdische Lebensformen verkauft wird, oder tzlich ein neuer Kontinent auftauchen sollte, dann kann man ganz pro- blemlos die betreffenden Sprachen und Auslandsvorwahlen inclusive des Zeitformats und der Wochentage einstellen. Seit der Version 1.1 ist Madhouse lokalisiert. Das hei t: Benutzer von OS 2.1 oder h her kommen in den Genu eines Madhouse mit deutschen Texten, OS 2.0 - User lesen nach wie vor alles auf englisch. Das stellt diese An- leitung auf eine harte Probe: englische und deutsche Texte m ssen gleich- zeitig erw hnt werden. Au erdem unterscheiden sich teilweise die Texte vom MUI-Programmteil von den Texten, die ohne MUI zu lesen sind. @{FG Highlight}@{B}Leider ist Madhouse seit vorgestern Commoditie.@{UB}@{FG Filltext} Wieso leider? Nun, Aicke und ich sind nicht gerade Fans von CX's (dumme Abk rzung..), weil man als Anwender immer das Problem hat, die Einstellungsfenster der Commo- dities zu ffnen. Denn viele C. bieten nur zwei M glichkeiten dazu: den Hotkey und das Exchange-Programm. Ersteres vergi t man dauernd, letzteres mu man erst starten. Weil Exchange selbst Commoditie ist, k te man es auch per Hotkey aufrufen, aber wenn man den auch vergessen hat... Naja, Commoditie-Hasser haben keine Probleme mit Madhouse, da man es ja ganz bequem mit dem Tools-Men aufrufen kann. Und die, die voll auf Commodities abfahren, k nnen Madhouse auch mit Exchange fernsteuern - wenn's denn unbedingt sein mu Madhouse ist aber nur deshalb Commoditie, weil sich das vom programm- technischen Aspekt ganz gut macht, so lassen sich Maus und Tastatur leicht und vor allem systemkonform abfragen. @{FG Highlight}@{B}Was Madhouse von anderen herk mmlichen Marken-Blankern unterscheidet:@{UB}@{FG Filltext} Die gro en Unterschiede liegen in den kleinen Details. So kann mit fast jeder Programmiersprache ein Blanker f r Madhouse erstellt werden, und kinderleicht ist es auch. Als Beispiel f r ein anderes Detail m chte ich die Madhouse-Zufalls-Funktion hervorheben, die zu gegebener Zeit einen der Blanker ausw hlt, damit er dann angezeigt werden kann. Weil dieses Kapitel aber eh' schon gro genug ist, und ich Euch den Code auf keinen Fall er- sparen m chte, m t Ihr jetzt @{"Hier klicken!",link bl_rand} Die anderen Features werden Euch beim Lesen der Anleitung bestimmt auch auffallen. @{FG Highlight}@{B}Ein paar Worte an die Einsteiger.@{UB}@{FG Filltext} Die Bedienungsanleitungen von Programmen, gleich ob kommerziell oder PD, nnen und sollen die Anleitung zur Bedienung des Computers nicht ersetzen. Wer also seinen Amiga noch nicht so lange besitzt, der sollte einerseits eine gute Computerzeitschrift lesen. ber solche Zeitschriften kann man etwas ber Neuerscheinungen auf dem Amiga-Markt erfahren. Zum Einsteigen rt aber meiner Meinung nach noch ein Einsteigerbuch, das auf Euren Computer zugeschnitten ist. Solche B cher sind noch erh ltlich und sind eigentlich immer um L ngen besser als Commodores Orginal-Anleitung. @{FG Highlight}@{B}Zum Schlu @{UB}@{FG Filltext} bitte ich alle interessierten Programmierer, doch mal ein eigenes Modul f r Madhouse zu schreiben, da die Schnittstelle recht gut beschrieben ist (in dieser Datei). Au erdem geht alles wirklich einfach, und kleine H rden werden mehr als ausf hrlich erkl rt. Viel Spa dabei. @{FG Highlight}@{B}Zum absoluten Schlu @{UB}@{FG Filltext} danke ich allen, die sich so lange mein Gequassel durchgelesen haben... Schreibt uns mal! F r Verbesserungsvorschl Anregungen, Lob und Kritik sowie geistige Aufbauma nahmen ("Wann kommt denn endlich das Update?") sind wir immer offen. Die Adressen findet Ihr einerseits im etwas berdimensionierten (ich geb' es ja zu..) Info-Fenster des Hauptprogramms ( ber Info-Button erreichbar) und im @{"Autoren- und Copyright-Anhang",link authors} @{B}Viel Spa @{FG Highlight} @{FG Fill} .@{FG Filltext} @{FG Highlight} //\ \ @{FG Fill} :@{FG Filltext} /\ : @{FG Fill} @{FG Filltext}( )@{FG Highlight} _______ @{FG Fill} /\/\/\/\ @{FG Filltext} /\ @{FG Highlight} / \ \ @{FG Fill} _.._-. :@{FG Filltext} || '@{FG Fill} __ @{FG Filltext}(.)@{FG Highlight} /_______\ @{FG Fill}< >@{FG Filltext} / \ /\\\ @{FG Highlight} | _ \ @{FG Fill} 8 \ :@{FG Filltext} || /\ @{FG Fill} / \ @{FG Filltext}(.)@{FG Highlight} || ||@{FG Fill} < >@{FG Filltext} / \ / \ @{FG Highlight} | |_| \ @{FG Fill} 8 ___ \:@{FG Filltext} || ||@{FG Fill} I /\ @{FG Filltext}( )@{FG Highlight} ||@{FG Filltext} ( )@{FG Highlight} ||@{FG Fill} > \/\/\/@{FG Filltext} / /\ \\// |@{FG Highlight} | |@{FG Fill} 8 | \ |@{FG Filltext} ||_||@{FG Fill} I || ! @{FG Filltext}( )@{FG Highlight} ||@{FG Filltext} (:)@{FG Highlight} ||@{FG Fill} > <@{FG Filltext} / / \______ |@{FG Highlight} | ___ |@{FG Fill} 8 * < |@{FG Filltext} |___|@{FG Fill} I || ! @{FG Filltext}( )@{FG Highlight} ||@{FG Filltext} ( )@{FG Highlight} ||@{FG Fill} < <@{FG Filltext} / / | |@{FG Highlight} || | |@{FG Fill} 8 | > |@{FG Filltext} || ||@{FG Fill} I || ! @{FG Filltext}( )____/ / @{FG Highlight}||@{FG Fill} < /\/\/\ @{FG Filltext} / | | |@{FG Highlight} || | |@{FG Fill} 8 |__/ |@{FG Filltext} || ||@{FG Fill} I || ! @{FG Filltext}\ ++++++/ @{FG Highlight}// @{FG Fill} > >@{FG Filltext} |___| | |@{FG Highlight} \/ : :@{FG Fill} 8 / @{FG Filltext} \/ ||@{FG Fill} | \/ ! @{FG Filltext} @{FG Highlight}// @{FG Fill} > \/\/\/@{FG Filltext} | |@{FG Highlight} . :@{FG Fill} 8_..../ @{FG Filltext} ||@{FG Fill} \__/ @{FG Highlight} ____// @{FG Fill} < <@{FG Filltext} | |@{FG Highlight} .@{FG Fill} 8 @{FG Filltext} \/@{FG Fill} @{FG Highlight} /____/ @{FG Fill} < <@{FG Filltext} \/\/@{FG Highlight} . @{FG Fill} 9 @{FG Filltext} @{FG Fill} @{FG Highlight} // @{FG Fill} > /\/\/\ @{FG Filltext} @{FG Highlight} .@{FG Fill} 0 @{FG Filltext} @{FG Fill} @{FG Highlight} || /\ @{FG Fill} > >@{FG Filltext} @{FG Highlight} @{FG Fill} 1 @{FG Filltext} @{FG Fill} @{FG Highlight} \\____//: @{FG Fill} < >@{FG Filltext} @{FG Highlight} @{FG Fill} : @{FG Filltext} @{FG Fill} @{FG Highlight} \____/ @{FG Fill} \/\/\/\/@{FG Filltext} w nschen Euch die Programmierer Aicke Schulz und Carsten Jahn.@{UB} @endnode @node bl_rand "Die Madhouse-Zufallsfunktions:" Also, beim Durchschnittsblanker w rde man so eine Funktion etwa so realisieren: short bl_random() return Random(b_counter) wenn b_counter die Anzahl der Blanker ist. In Madhouse sieht das so aus: short bl_random() short rd=0; BOOL takeIt = FALSE; BOOL Bl_Avail = FALSE; short used_min = 30000; short used_max = 0; short take_me_border = 0; // CPU-Tests? short cpu = 0; if( cpu_sensitive ) // Wenn CPU sensitive Random aktiv ist cpu = cpu_test(); // Zustand der CPU ermitteln (macht sie was?) // Ist berhaupt ein Blanker verf gbar? for( int i=0; i used_max ) used_max = b[i].used; } } // Jetzt enthalten: used_min wie oft der Blanker schon dran war, der am // wenigsten dran war und // used_max wie oft der Blanker schon dran war, der am // meisten dran war. take_me_border = used_min + (used_max-used_min)/2; // Die Gruppe der Blanker wird zweigeteilt. Einen Auftrittsz hler klei- // ner oder gleich take_me_border bedeutet, er war weniger dran als DIE // H LFTE der Blanker, will sagen da eine Menge Blanker schon // dran war als er. // Besser kann ich das nicht erkl ren... if( Bl_Avail ) { // Solange noch keiner herausgefischt wurde while( !takeIt ) { takeIt = TRUE; // Einen aus der Menge greifen rd=Random(b_counter); // Und sehen, ob er den Anforderungen gen // Wurde er etwa nicht ausgew hlt? Dann nix wie weg mit ihm. if( b[rd].rand_sel == 0 ) takeIt = FALSE; // Oder hatte er in dieser Blank-Periode schon einen Fehler ge- // meldet? Dann geht er jetzt sich auch nicht... und tsch if( b[rd].error == TRUE ) takeIt = FALSE; // Oder wurde CPU sensitive Random ausgew hlt UND die CPU ist // am kochen UND er w rde den Prozessor zu stark beanspruchen? if( cpu_sensitive && cpu && b[rd].CPU_need ) takeIt = FALSE; // Oder haben wir den vorhin schon gesehen? if( b[rd].used > take_me_border ) takeIt = FALSE; } } else // Kein Wunder - niemand hat sich gefunden... rd = -1; return rd; // Ergebnis ist -1, wenn kein passender Bl beschafft werden konnte. Kleine Anmerkung: Obwohl - wie hier ersichtlich - die Blankerdaten in einem Array gehalten werden, ist die Anzahl der maximal m glichen Blanker nicht limitiert. Dies k nnt ihr gerne durch hundertausendfaches Kopieren des CrazyPixel-Blankers nachpr fen. Ich habe das nicht ausprobiert... @endnode @node workshop "Der Workhop" Soo, da w ren wir nun. Eigentlich ist die gesamte Madhouse-Oberfl selbsterkl rend, wie man so sch n sagt. Aber wer kann schon von seinenen Programmen behaupten, da sie jeder versteht? Vielleicht Dr. Peter Kittel von seinen AmigaBASIC-Demos? Also dann, ab gehts: @{FG Highlight}@{B}0. Die Installation.@{UB}@{FG Filltext} ... sollte eigentlich ganz einfach gehen, denn das Installerscript zu Madhouse erledigt alles. Das dazu n tige Programm "Installer" solltet Ihr von Eurer Install-Disk (sofern Ihr eine habt, sonst von einem anderen Programm das den Installer verwendet) in Euer C:-Verzeichnis kopieren, dann m te alles laufen. Wer absolut nicht an den Installer herankommt, was jetzt aber echt ver- wunderlich ist, der mu halt alles "handy" machen: @{B}a) Zum schnellen Ausprobieren:@{UB} die amos.library aus dem Madhouse-Libs/- Verzeichnis in das libs-Verzeichnis der Startdiskette/-Festplatte kopieren. Das kann ber die Shell so geschehen: "copy Madhouse/libs/amos.library to sys:libs/amos.library". Vor "Madhouse" mu ggf. noch ein Pfad mit Diskettenbezeichnung stehen. Das war's dann schon, denn wenn das Programm "Madhouse" aus seiner ur- spr nglichen Schublade heraus gestartet wird, findet es das Ein- stellungsprogramm von allein. @{B}b) Zur dauerhaften Anwendung:@{UB} Wie das Wort "dauerhaft" schon andeutet, mu hier wieder die Schublade SYS:WBStartup/ herhalten. Aber zuerst die amos.library kopieren, wie unter a) beschrieben. Nun das Programm "Madhouse" nach SYS:WBStartup kopieren. Alle Programme in dieser Schublade werden dann beim Hochfahren des Rechners automa- tisch gestartet. Benutzer von Disketten sollten das gesamte Madhouse- Verzeichnis auf einer neuen Leerdiskette auslagern, HD-User legen ein neues Verzeichnis an und kopieren die Madhouse-Schublade dort hinein. Jetzt mu nur noch das ToolType ("Merkmal") im Madhouse-Icon (dem Mad- house-Piktogramm in WBStartup) ge ndert werden. Die Zeile CONFIGED= sagt Madhouse, wo sich das separate Einstellungsprogramm f r Madhouse befindet, welches Madhouse ggf. selbst starten mu . Man mu diesen ToolType so ndern, da er den neuen Pfad und den Programmnamen des MadhouseConfigEd-Programs enth lt - also je nach dem, wohin man das Madhouse-Verzeichnis kopiert hatte. Damit - falls dies ein Amiga mit OS 2.1 oder h her ist - Madhouse die mitgebrachte Locale-Datei benutzen kann, um alles auf deutsch anzu- zeigen, mu noch die Datei Locale/deutsch/madhouse.catalog aus dem Madhouse-Verzeichnis nach LOCALE:catalogs/deutsch/madhouse.catalog kopiert werden - und fertig. @{FG Highlight}@{B}1. Der Programm-Start.@{UB}@{FG Filltext} Das sollte kein gro es Problem darstellen. Wie auf dem Amiga blich, geschieht dies per Doppelklick auf das Madhouse-Icon. Falls der Computer nicht mit dem Amiga-OS 2.0 ausger stet ist, ist das schlecht, denn in diesem Fall gibt Madhouse nicht mehr als einen simplen Alert aus... Au erdem *mu * die amos.library im "LIBS:"-Verzeichnis vorhanden sein, aber das haben wir ja eben erledigt. (Nur, falls jemand mittels "assign add LIBS: xxx" mehrere Suchpfade f r LIBS: erstellt hat, noch ein Hinweis: die amos.library mu sich in dem Verzeichnis befinden, was zuerst als LIBS: deklariert wird, also normalerweise sys:libs. Sonst st rzt der n chstbeste AMOS-Blanker ab. Sorry, aber so ist das halt bei AMOS.) @{FG Highlight}@{B}2. Ein Fenster ffnet sich.@{UB}@{FG Filltext} Und das ist schon einen Faszination f r sich, denn bei installiertem MagicUserInterface ( Stefan Stunz, folgend MUI genannt, siehe auch @{"MUI-Infos",link mui_info}) reagiert der MadhouseConfigEd entsprechend und ffnet ein MUI-Fenster, sonst nur ein normales. Ihr habt richtig ge- lesen, im Moment und eigentlich immer bedient Ihr den MadhouseConfigEd und nicht Madhouse selbst. (Madhouse hat soeben dieses Programm ge- startet). Falls nicht, wenn sich also kein Fenster ffnet, ist bereits alles in Ordnung. Beim Erststart wird Madhouse allerdings nicht seine Datei mit den Einstellungen finden k nnen, so da es das Hauptfenster ffnet. Wenn Ihr das Fenster "von Hand" ffnen wollt, dann - braucht Ihr keinen Hot-Key zu dr cken, den Ihr immer verge t, und - Ihr braucht nicht das Exchange-Programm zu starten, das Ihr immer l scht... Ein Blick ins Tools-/Hilfsmittel-Men bringt Klarheit, Madhouse tr sich praktischerweise hier ein. Bei Anwahl Fenster. Wenn anstatt eines tollen Fensters ein fader Requester erscheint, der etwas von einem falschen Pfad labert, dann folgt den Anweisungen und beendet Madhouse (Requester best tigen und Madhouse nochmals starten), ndert den CONFIGED-Tooltype (siehe Abschnitt 0) und startet Madhouse neu. @{FG Highlight}@{B}3. Jetzt den Pfad der Blanker angeben!@{UB}@{FG Filltext} Durch einen Klick auf den kleinen Knopf mit dem Bildchen (neben dem Path-Gadget) ffnet sich der ASL-Directory-Requester, in dem ihr jetzt das Verzeichnis mit den Blankern angeben k nnt. Auf der unge nderten Madhouse-Disk hei t dieses Verzeichnis "Blankers". Wichtig: Der Pfad mu mit dem NAMEN einer Diskette beginnen (z.B. "Work:.../Blankers"), sonst macht Euch Madhouse darauf aufmerksam und akzeptiert nix. Nachdem der Requester mit "Ok" best tigt wurde, sollten in der Listbox auf der linken Seite des Hauptfensters Namen wie "FlyingToasters" stehen. Au erdem werden nun die restlichen Gadgets nicht mehr schraffiert dargestellt. r Einsteiger, die ihren Wortschatz aufstocken wollen: Dieses Gadget "mit dem Bildchen" hei t Popup-Button. @{B}- Wer keine Festplatte hat...@{UB} der kann Madhouse auch benutzen. Jedoch mu dann der Schalter "Puffern/Buffering" im Advanced-Options-Fenster bzw. auf der Optionen/ Advanced-Seite im MUI-Fenster aktiviert sein. Das geschieht schon standard-m Da Madhouse sehr gut auf den Diskettenbetrieb abgestimmt ist, aber oberfl chlich davon nur dieses "Puffern/Buffering"-Gadget zu sehen ist, empfehle ich noch die Lekt re von @{"Alles ber Buffering",link buffering}. @{B}- Wer aber eine Festplatte hat...@{UB} Der kann die Option "Puffern/Buffering" im Advanced-Options-Fenster (bei MUI: auf der Optionen/Advanced-Seite) ausschalten. Doch dazu sp ter mehr. Nat rlich reicht es nicht, eine Festplatte zu haben, Madhouse mu auch dort installiert sein... @{FG Highlight}@{B}4. Nun sehen wir uns die Blanker-Module an!@{UB}@{FG Filltext} @{B}Ohne MUI:@{UB} Zuerst mu das Edit-Gadget durch draufklicken weitergeschaltet werden, bis der Text "Einstellung/Prefs..." erscheint. In diesem Modus k die Einstellungen des Blankers ge ndert werden, den man in der unteren Liste ausw hlt. Also bitte einen Blanker anw hlen! @{B}Mit MUI:@{UB} Zuerst m t Ihr das Registerfeld (oder das Cycle-Gadget) von "System" auf "Blankers" umschalten. Nun erscheint wieder fast dieselbe Liste auf der linken Seite des Fensters. Bitte auf einen Blanker doppel- klicken. @{B}Weiter f r mit und mit ohne :^) MUI:@{UB} Schon ffnet sich ein Fenster, in dem sich u.a. ein Knopf mit der Aufschrift Test befindet. Anklicken und staunen! Durch einen weiteren Mausklick wird der Blanker dann wieder beendet. "Abbruch/Cancel" und "Okay" ffnen wieder das Hauptfenster, wobei "Okay" die Einstellungen abspeichert. "Dauer/Duration" (bei MUI im Haupt- fenster, sonst im eben ge ffneten BlankerPrefs-Fenster) wird im Refe- renzteil erkl Die anderen Gadgets variieren je nach Blanker. Hier bieten sich viele M glichkeiten zum Herumspielen, beeinflussen diese Gadgets doch den Blanker. Ihre Bedeutungen werden dann im Blanker-Kapitel erkl Jetzt k nnt Ihr erstmal alle Blanker ausprobieren. @{FG Highlight}@{B}5. Die Liste(n) mit den Blanker-Namen und was da so passiert:@{UB}@{FG Filltext} @{B}Ohne MUI:@{UB} Der Edit-Button bestimmt, was passiert, wenn ein Blanker in der Liste ausgew hlt wird. Steht er auf "Einstellung/Prefs..." kann, wie eben geschehen, das BlankerPrefsFenster ge ffnet werden. Mit "Auswahl/Selection" wird bestimmt, welche Blanker benutzt werden, wenn Madhouse nach der angegebenen Zeit die Blanker startet. Durch Klick werden sie angeschaltet ( CrazyPixel) und wieder ausgeschaltet ( CrazyPixel). @{B}Mit MUI:@{UB} Die Liste, die auf der Blankers-Seite angezeigt wird, erm glich das dern der Einstellungen der einzelnen Blanker. Die andere Liste, auf der System-Seite vorhanden, dient dem Ausw hlen der einzelnen Blanker. Mit Ihr wird bestimmt, welche Blanker gestartet werden sollen, wenn der Computer ber eine einstellbare Zeitspanne hinweg keine Eingaben empfangen hat. @{FG Highlight}@{B}6. Wieviel Zeit meiner Inaktivit t soll vergehen, bis Madhouse loslegt?@{UB}@{FG Filltext} Diese Einstellung wird mit dem "Zeit/Time"-Slider erledigt. @{FG Highlight}@{B}7. Konfiguration speichern.@{UB}@{FG Filltext} Ganz einfach mit "Speichern/Save". Dann wird die Konfiguration als "ENVARC:Madhouse.prefs" abgespeichert. @{FG Highlight}@{B}8. Wer keine Festplatte hat oder ein Pa wort braucht,@{UB}@{FG Filltext} Klickt hier: @{"Die (Advanced) Options", link adv_op} @endnode @node adv_op "Das Advanced Options Fenster / Die Advanced/Optionen-Seite" Dieses Fenster stellt einige weitere Funktionen bereit, die man selten ndert. @{FG Highlight}@{B}1. Pa rter@{UB}@{FG Filltext} r Zeitgenossen, die anderen alles zutrauen und f r Leute, die den Amiga beruflich nutzen (ja, das gibt's!), haben wir eine Pa wort- Funktion zur Verf gung gestellt, die sich kaum umgehen l t (was mir bereits zum Verh ngnis wurde...) "Kaum" hei t, es wurde durch keinen Versuch die Sicherheit des Eingabescreens widerlegt. Und wir haben wirklich alles ausprobiert. Jedoch kann Madhouse auf Systemen ohne Festplatte den neuen Blanker nach @{I}Abbruch@{UI} der Pa worteingabe nicht so schnell starten, was zur Folge hat, da in dieser Zeit dann doch Ver nderungen an den Pro- grammen im Hintergrund vorgenommen werden k nnen. Also ausprobieren! Wenn Ihr ein Pa wort wollt, m t Ihr zun chst den Haken vors "Password/Pa wort/Benutzen"-Gadget setzen. Dann sollte noch ein m lichst gerissenes Pa wort in das Text-Feld "Name" (bzw. "Text") einge- geben werden. 4711 w rde nat rlich jeder Gangster zuerst ausprobieren, besser sind da ausgefallenere Dinge: "Schnellhefter", "ALDI", "Rasen- her", "Hundshai", ... Ach, ja.. es ist recht hilfreich, wenn man das Pa wort nicht vergi t. Nach der Einstellung des Pa worts fragt Madhouse gleich nach demselben; was sich also nicht eingeben l t wird gleich und ohne Probleme durch das alte Pa wort ersetzt. Nachdem ein Blanker gestoppt wurde, erscheint dann der Pa wort-Screen. Es ist zwar kein Cursor im Textfeld zu sehen, aber Ihr k nnt einfach lostippen. Jedes Zeichen wird als "*" dargestellt. Es gibt drei Chancen, das richte Pa wort zu finden, aber ist das dritte falsch, verstreichen ein paar Minuten seit der letzten Eingabe, oder es wird Esc gedr ckt, startet der n chste Blanker. Backspace funktioniert wie gewohnt, und Return best tigt das Pa wort. Zwischen Gro - und Kleinschreibung wird fieserweise unterschieden! @{FG Highlight}@{B}2. Optionen f r Disketten-Benutzer@{UB}@{FG Filltext} Wenn Ihr keine Hard-Disk habt, ist Madhouse der einzige modulare Screenblanker, den Ihr benutzen k nnt (soweit ich wei Was passiert wohl, wenn man einen herk mmlichen Marken-Mod.-Screenbl. startet, der seine Module nur auf einer Diskette sucht? Sofern beim Start des Blankvorgangs mal die ben tigte Disk nicht im Drive liegt, startet die Workbench ihre eigene Show: Ein netter "Please insert Disk..."-Requester brennt sich in Eure Phosphorschicht. Wenn man "Puffern/Buffering" im Advanced-Options-Fenster aktiviert, ist soetwas mit Madhouse nicht m glich. Madhouse l dt dann immer einen Blanker in sein RAM:Madhouse_Storage-Verzeichnis, das es beim Programm- Start automatisch anlegt. Wurde dieser Blanker dann gezeigt, und die Diskette mit den Madhouse-Blankern liegt WIRKLICH im Drive (wird vor- sichtig gepr ft), dann l dt Madhouse einen frischen Blanker nach. Wenn Ihr zus tzlich "@{B}Nach Disk fragen/Ask for Disk@{UB}" anw hlt, zeigt Euch Madhouse mit einem kleinen Fenster auf der Workbench an, da der ge- pufferte Blanker bereits benutzt wurde und da Madhouse darauf lauert, da die Blankers-Diskette eingelegt wird. Ein Klick auf das Schlie -Gadget dieses kleinen Fensters bewirkt nicht nur das Schlie en des Fensters, sondern stellt auch alle Schn ffel- versuche nach der Diskette ein. Madhouse kopiert au erdem die libs:amos.library in sein Storage- Verzeichnis, da die Amos-Blanker diese ben tigen. @{FG Highlight}@{B}3. Der "Schwarze Hintergrund/Black Background"@{UB}@{FG Filltext} Wer Disketten benutzt, hat sicher schon die oft sekundenlangen Ladezeiten der Blanker bemerkt. Wer mehrere Blanker ausgew hlt hat und "Blanker wechseln/Exchange Blankers" benutzt, bekommt beim Blanker- wechsel immer kurz die Workbench zu sehen (sofern die Disk mit den Blankern im Laufwerk liegt, sonst kann Madhouse ja nicht wechseln). Wenn Euch das st rt, k nnt Ihr "Hintergrund ffnen bzw. Benutzen / open Background" aktivieren. Dann bleibt der Screen in den Ladezeiten schwarz. Wer zus tzlich "Info-Texte/and show info-texts" anw hlt, be- kommt auf diesem schwarzen Screen noch die Texte "Lade neuen Blanker/ Loading new blanker." und das beliebte "Bitte noch etwas Geduld.../Wor- king. Please wait..." angezeigt! @{FG Highlight}@{B}4. Die anderen Optionen: "Other Options"@{UB}@{FG Filltext} Das Fenster der erweiterten Optionen bietet auch noch zwei "andere Optionen": Beginnen wir mit der interessanteren: "@{FG Highlight}CPU active:@{FG Filltext}" Zuerst einmal mu erkl rt werden, da verschiedene Programme und bestimmte Dinge den Prozessor Eures Computers mehr oder weniger be- lasten. Generell kann man sagen, da die sog. CPU ausgelastet ist, wenn ein Programm etwas tut und Ihr warten m t. Z.B. bei irgend- welchen Rechnungen. hrend PC-Freaks noch froh sind, wenn sie gleichzeitig einen Text Drucken UND eine Diskette formatieren k nnen, k nnt Ihr auf Eurem Amiga ohne gr ere Probleme ein Bild berechnen und einen Text schrei- ben. Man beachte, da das mit dem Amiga 1986 m glich war, und da IBM 1994 mit OS 2 daf r Werbung macht... Also zur ck. Wenn nun zwei @{I}rechenintensive@{UI} Programme gleichzeitig laufen, also praktisch zwei Bilder berechnet werden, werden beide Bilder halb so schnell berechnet. Und jetzt kommts: Wer ein Bild berechnet und dabei einen rechenintensiven Bildschirmschoner laufen l t, merkt 1. da Bild halb so schnell berechnet wird und da 2. der Blanker halb so schnell l uft. Und das ist gleich zweifach rgerlich. Deshalb gibt es in Madhouse das "CPU active:"-Gadget. Es hat drei m liche Zust - "alle Blanker/use all Blankers" k mmert sich nicht um die CPU, so da der o.a. Fall eintreten k nnte. - "(nur) einfache Blanker/only simple ones" berpr ft die CPU, ist sie aktiv wird ein Blanker gestartet, der die CPU fast gar nicht belastet. Wurden nur Blanker ausgew hlt, die viel Rechenzeit ben tigen, er- scheint ein schwarzer Bildschirm und sp ter die Mitteilung, die auf diesen Notstand aufmerksam macht. - "nichts anzeigen/show nothing" zeigt den schwarzen Screen immer, wenn die CPU besch ftigt ist. Diese Funktion ist brigens voll kompatibel zur "Puffern/Buffering"- Option. Nur falls der gepufferte Blanker "viel" CPU braucht, ein Progr. auch viel CPU braucht und "CPU active:" auf "only simple Blankers" steht UND die Disk mit den Blankern nicht im Laufwerk liegt, seht Ihr auch den schwarzen Screen. Wenn Ihr wissen wollt, wie sowas im Programmcode aussieht, dann fragt lieber nicht... Wenn Ihr wissen wollt, welche Blanker denn nun rechenintensiv sind und welche nicht, hier steht es:@{"die Blanker",link blankers}. Mit MUI l t sich das einfacher herausfinden, einfach auf die "Blan- kers"-Seite wechseln und den fraglichen Blanker @{i}einmal@{UI} anklicken. Dann wird im Feld "CPU-Belastung/CPU load" folgendes angezeigt: - "niedrig/low" wenn der Blanker nicht rechenintensiv ist; und - "mittel bis hoch/medium to high" wenn er es ist. Die zweite Option dieser Rubrik hei t "@{FG Highlight}Blanker-Pri@{FG Filltext}" und ist ber ein (echt niedliches) Cycle-Gadget erreichbar. Wie der Name verspricht, nnt Ihr damit bestimmen, mit welcher Priorit t die Blanker laufen sollen. Eine Taskpriorit t kann zwar zwischen -128 und 127 tendieren, sinnvoll sind hier aber die Werte 0 und 1. Deshalb das Cycle-Gadget. r den Fall, da zwei Programme gleichzeitig rechnen, hat der Amiga die Task-Priorit ten. Dann wird das Programm mit der h heren Priorit t zuerst abgearbeitet, das Programm mit der niedrigeren bekommt nur noch ganz wenig vom Prozessor. Normalerweise laufen alle Anwendungen mit der Priorit Rechnet nun also ein Programm (kanonisches Beispiel: Raytracer) und ein rechenintensiver Blanker wird mit der Priorit t 1 gestartet, bleibt dieses praktisch stehen. Deshalb sollte man bei "CPU active:" = "alle Blanker/use all Blankers" immer 0 w hlen. Da bei "CPU active:" = "(nur) einfache Blanker/only simple Blankers" so- wieso nur ein Blanker mit niedriger CPU-Belastung gestartet wird, wenn ein Programm rechnet, kann man in diesem Fall ruhig 1 w hlen. Dann l der Blanker viel fl ssiger und die Anwendung kann trotzdem weiterrech- nen. Trotzdem mu das nicht die beste Einstellung sein, denn wenn einem Programm mitten beim Blanken anf ngt zu rechnen, geht es ziemlich leer aus. Ein Beispiel w re ein Backup-Programm, was abwechselnd Dateien packt und schreibt. Das Packen ist rechenintensiv, das Schreiben weni- ger. Wenn nun Madhouse die Prozessorauslastung gerade beim Schreiben berpr ft, kann es gut sein, da ein Blanker mit hoher CPU-Belastung gestartet wird, und das Backup-Programm beim Packen arg verlangsamt wird. Und dann gibt's noch - vorerst nur f r MUI-User - den "@{FG Highlight}Sound@{FG Filltext}"- Button. Mit ihm l t sich bestimmen, wie das Sound-System von Madhouse arbeiten soll. Auf der Blanker-Seite kann man ja f r jeden Blanker ein Musik-Modul einstellen, was dann nat rlich irgendwie abgespielt werden mu . Das ist vielleicht total schade, aber ich war tats chlich zu faul einen kompletten Musik-Modul-Abspieler mit 70 unterst tzen Formaten und modularen Konzept auf Assemblerbasis mit diversen Zusatzfunktionen zu programmieren. Aus zwei Gr nden: 1. ich kann kein Assembler (was soll man denn noch alles k nnen, Computer sind in mancherlei Hinsicht echt anspruchsvoll), und 2. sowas gibt's schon. (Ok, das Argument zieht nicht ganz, es gibt auch schon etliche Screenblanker). Deshalb bin ich die Sache anders angegangen: Madhouse spielt nicht, son- dern l t spielen. Dabei kann Madhouse zwei Sound-Quellen ansteuern: 1. die medplayer.library vom MED-Programmierer Teijo Kinnunen, die sinn- gem nur MED spielt und 2. DeliTracker von Delirium Softdesign (Peter Kunath and Frank Riffel). Der DeliTracker ist der h rteste Modul-Player, den ich kenne. Er spielt so gut wie alles, und wird per ARexx ferngesteuert. Ihr k nnt nun zwischen einer der Varianten w hlen, und zwar mittels des Sound-Gadgets. Obwohl Madhouse den DeliTracker mittels ARexx steu- ert, mu dazu nicht das Programm RexxMast aus der System-Schublade laufen (darf aber). Die ARexx-Kommunikation zwischen zwei Programmen kann vollst ndig ber die rexxsyslib.library erfolgen, die dann auto- matsch in Euren Speicher gestopft wird. Wenn Ihr also mehr als MED-Module abspielen wollt, dann mu die Ein- stellung "via DeliTracker" lauten. ("via" hei brigens "auf dem Wege ber" und ist damit das lateinische Pendant f r einen ARexx-Port, blo rzer!) Wer @{B}Es ist mir sehr wichtig, dies auch hier nochmals zu erw hnen: f r die Sound-Funktionen von Madhouse ist eine Festplatte notwendig, damit die betreffende Datei erreichbar ist.@{UB} @endnode @node blankers "Alle Blanker in der bersicht" Hier ist der Nachschlageteil f r unsere Blanker, alphabetisch geordnet und mit allen n tigen Infos. @{" CrazyPixel ", link b_crazypixel} @{" DigitalClock ", link b_digitalclock} @{" Drops ", link b_drops } @{" Fireworks ", link b_fireworks } @{" FlyingToasters ", link b_flyingtoasters } @{" Glitter ", link b_glitter } @{" Memory ", link b_memory } @{" Note ", link b_note } @{" Shuffle ", link b_shuffle } @{" Skyline ", link b_skyline } @{" Soccer ", link b_soccer } @{" SoftwareFailure ", link b_softwarefailure } @{" Stars ", link b_stars } @{" Thunder ", link b_thunder } @{" Waves ", link b_waves } @{" Worldtime ", link b_worldtime } @{FG Highlight}@{B}Bitte beachten:@{UB}@{FG Filltext} Der Duration-Slider und die Gadgets am unteren Rand des BlankerPrefs-Fensters sind in @{"Referenz/BlankerPrefs-Fenster", link ref_editPrefs} er- rt. Der Wert des "Dauer/Duration"-Sliders wird nicht mit Okay abgespei- chert, sondern NUR mit der Save-Funktion im Hauptfenster. Trotzdem mu dann das BlankerPrefs-Fenster mit Okay verlassen werden, damit der Wert akzeptiert wird. @endnode @node b_crazypixel "Die Blanker in der bersicht - CrazyPixel" @{FG Highlight}@{B}CrazyPixel@{FG Filltext}@{UB} Von Aicke Schulz, Version 1. Dieser Blanker zeigt einen springenden Punkt sowie den Wusel. Mode/Modus: schaltet zwischen Wusel und Bouncing Point um. Ist Random ausgew hlt, wird zuf llig ein Modus benutzt. Wusell nge/Wusel lenght: ist die L nge des Wusels. Toneffekt/Sound: macht Ger usche zum Bouncing Point. Fehlermeldungen: siehe @{"AMOS-Errors",link amos_errors}. CPU-Belastung: Niedrig. Speicherverbrauch:160 kB. Programmgr e:25 kB. @endnode @node b_digitalclock "Die Blanker in der bersicht - DigialClock" @{FG Highlight}@{B}DigitalClock@{FG Filltext}@{UB} Von Aicke Schulz, Version 1. Wie viele andere Blanker hat auch Madhouse eine Uhr. Diese benutzt aber einen echten Digital-Font, wie er auch bei den beliebten Uhrenradios zu finden ist. Achtung: Wenn die Uhr falsch geht, dann liegt das ent- weder daran, da die interne Uhr des Amigas falsch gestellt ist oder da ihr kein Akku zur Verf gung steht. Sprache/Language: Hier k nnen auch ein deutsches Datum und deutsche Texte f r diesen Blanker gew hlt werden. Countdown: Wenn dieser Wert nicht Null ist, ert nt ein Klingeln nach Minuten nach dem Start des Blankers. Datum/Date: schaltet das Datum ein. Rollen/Scroll: bewegt die Uhr. Fehlermeldungen: siehe @{"AMOS-Errors",link amos_errors}. CPU-Belastung: Niedrig. Speicherverbrauch:180 kB. Programmgr e:34 kB. @endnode @node b_drops "Die Blanker in der bersicht - Drops" @{FG Highlight}@{B}Drops@{FG Filltext}@{UB} Von Aicke Schulz, Version 1. Tropfen laufen ber den Screen. Sie haben unterschiedliche Geschwindigkeit- en und sind in der Farbe nderbar. Aicke hat mit viel Liebe zum Detail die Drops gezeichnet. Von hunderten von Farbsets sind die sch nsten aus- hlt worden. Sie faszinieren mit ihren warmen, hellen Eindr cken oder lassen die Gedanken des Betrachters im tiefen Blau versinken. Ohne zu bertreiben mu ich sagen, da diese Farben wirklich einmalig in der ge- samten Welt der Amiga-Screensaver sind. Doch stellen wir sie einzeln vor: Ocean wird seinem Namen wirklich gerecht. Ocean zeugt noch von der Zeit, als die Ozeane klar und unverseucht waren. Ein heutiges Ocean halte ich r unm glich, m ten doch Giftm sser und russische Atom-U-Boote durch- schimmern. Wine ist von seiner ganzen Farbpracht ein Genu . Es springt regelrecht aus dem Monitor und und bezaubert durch die Anmutigkeit der Farbe. Grass erz hlt von gr nen Wiesen, spielenden Kindern und grasenden Schafen. Grass ist wie ein Tag im Wald, l t den Zuschauer frei assoziieren und die Augen mit dem tiefen Gr n verschmelzen. Caramel: Gold-gelb und sooooo sanig-s . Das hat mir mein Gro vater schon geschenkt. Und was gebe ich heute meinem Enkel? Fresh erinnert an einen Sonntagmorgen, an die Str nde von Miami Beach und Ibiza. So hell ist die Farbe, da sich kaum das Licht darin bricht. Fresh ist frisch. Da soll Aicke mal sagen, ich w rde seine Blanker kurz abhandeln... Gr e an alle Kunstlehrer! Anzahl/Number: Anzahl der Drops, die maximal gleichzeitig auf dem Screen sind. Farbe/Color: Der absolute MEGA-Mix der 5 Farbpaletten. Random l t den Blanker selbst w hlen. Fehlermeldungen: siehe @{"AMOS-Errors",link amos_errors}. CPU-Belastung: Niedrig. Speicherverbrauch:180 kB. Programmgr e:17 kB. @endnode @node b_fireworks "Die Blanker in der bersicht - Fireworks" @{FG Highlight}@{B}Fireworks@{FG Filltext}@{UB} Von Carsten Jahn, Version 1. Dieser Blanker zaubert ein tolles Feuerwerk auf Euren Bildschirm. Es stehen vier Effekte zur Verf gung. Mit den Slidern bestimmt man, wie oft ein Effekt verwendet wird. Wenn die Slider nicht zu hoch gesetzt werden, hat FireWorks noch M glichkeiten, die Farben zu ndern. So ent- stehen immer neue Farben, obwohl kein Effekt "mittendrin" die Farbe wechseln mu . Will sagen: man merkt nur, da tzlich ein neuer Effekt in einer neuen Farbe erscheint, Effekte, die schon auf dem Screen sind, werden nicht beeinflu Spiralen/Spirals: bestimmt, wie stark die Spiral-Effekte vertreten sind. Font nen/Jets: bestimmt, wie stark die Font nen vertreten sind. B lle/Balls: bestimmt, wie stark die Kugeln vertreten sind. Farb-Font nen/Color-Jets: bestimmt, wie stark die Mehrfarb-Font nen ver- treten sind. Pixelgeschw./Pixelspeed: Nat rlich schafft es Fireworks schneller, wenige Punkte zu zeichnen als viele. Wenn nur wenige Punkte auf dem Bildschirm sind, mu Fireworks deshalb fter Pausen einlegen, damit die Anzeige nicht optisch langsamer wird wenn mehr Punkte hinzukommen. Mit Pixelgeschw. kann man nun ein- stellen, wie gro die Pausen bei wenigen Punkten werden. Hier mu man einfach etwas herumpro- bieren, bis der Effekt nicht mehr schneller und langsamer wird. CPU-Belastung: Hoch. Speicherverbrauch:110 kB. Programmgr e:17 kB. @endnode @node b_flyingtoasters "Die Blanker in der bersicht - FlyingToasters" @{FG Highlight}@{B}FlyingToasters@{FG Filltext}@{UB} Von Carsten Jahn, Version 1. Boh ey, guck 'ma da fliegt'n Toaster! Kleine, drollige Wesen mit Fl und gl henden Toast-Slots schwingen sich ber den Screen. Aus leblosen chenknechten werden niedliche Gestalten, aus dem morgendlichen Fr werden Hindernisse, schon beginnt der Spa . Die auf- und abrutschenden Auswurfhebel erschrecken die Toasts auch nicht, keines springt beiseite. Folge: jeder 20ste Toaster in Deutschland ist eingeklemmt. Wohin soll das noch f hren? Was wei ich. Spendet jetzt aber nicht f r eingeklemmte Toaster, sondern lieber f r verkohlte Toasts, die haben ein viel schlimm- eres Leben. Toaster/Toasters: max. Anzahl der Toasters auf dem Screen. Toasts: max. Anzahl der Toasts auf dem Screen. Geschw./Speed: bestimmt die Geschwindigkeit des Blankers. Marmelade/Jam: schmiert Marmelade, Honig oder Nutella auf die Toasts. Das perfekte Fr Double Buffering: schaltet Double-Buffering ein. Dadurch wird das Flackern der bewegten Objekte vermieden. Ben tigt mehr Speicher. Ist dieser nicht vorhanden, wird vor dem Totalabbruch noch ein Versuch ohne diese Option gemacht. Leerer Start/Endscreen / In/Out Moving: Ist diese Option abgeschaltet, so erscheinen die Toasters und Toasts beim Blankerstart pl tzlich und sind auch noch mitten auf dem Screen, wenn der Blanker abbrechen mu Wird "In/Out Moving" jedoch aktiviert, fliegen die Toasts und Toasters erst rechts herein, der Blanker beginnt mit einem schwarzen Bildschirm. Eine den Einstellungen und Prozessortyp angemessene Zeitspanne vor Ablauf der Dura- tionzeit werden dann keine neuen Toasts mehr erscheinen, so da sich der Blanker auch wieder mit einem leeren Screen verabschiedet. Das zeitgem e Herausfliegen klappt nat rlich nur bei aktiviertem "Blanker wechseln/Exchange Blankers", da sonst der Blanker ja noch bis ins Jahr 3000 laufen k te. CPU-Belastung: Hoch. Speicherverbrauch:297 kB. Programmgr e:29 kB. @endnode @node b_glitter "Die Blanker in der bersicht - Glitter" @{FG Highlight}@{B}Glitter@{FG Filltext}@{UB} Von Aicke Schulz, Version 1. Glitter ist sicher nicht das Genialste, was Ihr jemals gesehen habt, aber trotzdem ganz nett. Anzahl/Number: Anzahl der Sterne. Dies verlangsamt den Start des Blankers, jedoch nicht die Ani- mation. Geschwindigkeit/Cyclespeed: Geschwindigkeit des "Glitterns". Fehlermeldungen: siehe @{"AMOS-Errors",link amos_errors}. CPU-Belastung: Niedrig. Speicherverbrauch:218 kB. Programmgr e:15 kB. @endnode @node b_memory "Die Blanker in der bersicht - Memory" @{FG Highlight}@{B}Memory@{FG Filltext}@{UB} Von Aicke Schulz, Version 1. Das ist eine gute M glichkeit, mal einen Blick in den Speicher des Amiga zu werfen. Hier werden alle Daten als Grafik abgebildet. So erscheinen die ge ffneten Screens und viele andere Dinge, die man nat rlich nicht erkennt. Da der Amiga nach einem Reset nicht alle Daten l scht, sondern nur zum berschreiben freigibt, lassen sich oft noch Grafiken eines zuvor gestarteten Spiels erkennen - nat rlich in die Bitplanes aufge- spalten und deshalb zweifarbig. Jedenfalls sieht man immer was Neues... brigens wird nur das erste MegaByte ChipRAM angezeigt. Geschwindigkeit/Speed: bestimmt die Geschwindigkeit des Scrollens. Fehlermeldungen: siehe @{"AMOS-Errors",link amos_errors}. CPU-Belastung: Niedrig. Speicherverbrauch:180 kB. Programmgr e:14 kB. @endnode @node b_note "Die Blanker in der bersicht - Note" @{FG Highlight}@{B}Note@{FG Filltext}@{UB} Von Aicke Schulz, Version 1. Ganz nach Belieben erf llt Note gleich zwei Aufgaben in einem Blanker: Einerseits kann den Leuten, die am Computer vorbeigehen oder die etwas vom Benutzer des Computers wollen, eine Nachricht angezeigt werden. Anderer- seits ist auch der umgekehrte Weg m glich, die Anderen k nnen eine Mittei- lung eingeben und der Benutzer kann sie lesen. Um die Sache abwechslungs- reich zum machen, hat Aicke noch drei verschiedene Papier-Typen gezeichnet, auf denen wird dann geschrieben und angezeigt. Papier/Paper: Mit diesem Schalter wird der Papier-Typ ausgew "Granit(e)" ist ein Betonklotz, "Mittelalter/Medival" ist ein Mittelalter(-Papier nat rlich...) und "gegen/Against AIDS" ist gegen AIDS. Anders als Granit(e) und Mittelalter /Medival ist Against AIDS keine eigene Erfindung, diese Notizbl cke gibt's wirklich. Sie sind erh ltlich bei der Bundeszentrale f r gesundheitliche Aufkl Postfach 910152 5000 K ln 91 (Sorry - die neue Postleitzahl stand nicht da). Bestell-Nr. 70551000. Modus/Mode: Schaltet zwischen dem Empf nger- und Versender-Modus um. Bei "Nachricht geben/Give Message" werden die nebenstehenden Texteingabefelder zur Anzeige eines Textes benutzt. Dabei mu jede Eingabe mit abgeschlossen werden. "Nach- richt bekommen/Get Message" l t die Besucher eintippen und den Benutzer lesen. Wenn "Blanker wechseln/Exchange Blan- kers" nicht aktiv ist, oder der Blanker noch arbeitet wenn der Benutzer zur ckkommt, dann kann er den Text noch lesen.Wenn aber die Duration-Zeit von Note um war und ein neuer Blanker gestartet wurde, kann der Benutzer die Nachricht nach dem Wegklicken des Blanker in der Error-List lesen. ruhend/Static: Damit sich der Notizzettel nicht in der Phosphorschicht des Monitors einbrennt, l t sich mit "Static" die Zeit be- stimmen, nach der der Zettel wieder seine Position wechselt. Textzeilen/ Textlines: Dies sind die Schreibfelder. Jedes Schreibfeld steht f eine Zeile auf dem Notizblatt. Bei Against AIDS k nnen die letzten drei Zeilen nicht verwendet werden, weil da unten Platz fehlt. Auf einer MUI-Oberfl che haben diese Gadgets die Shortcuts 1 bis 7 (linke Spalte) und a bis h (rechte Spalte), c ausgenommen. Fehlermelungen: Die Nachricht, wenn dies so eingestellt wurde. erdem die blichen @{"AMOS-Fehlermeldungen",link amos_errors}. CPU-Belastung: Niedrig. Speicherverbrauch:210 kB. Programmgr e:48 kB. @endnode @node b_shuffle "Die Blanker in der bersicht - Shuffle" @{FG Highlight}@{B}Shuffle@{FG Filltext}@{UB} Von Carsten Jahn, Version 1. Habt Ihr schon einmal einen modularen Screenblanker ohne Shuffle-Modul gesehen? Ich nicht... Jedoch ist dieser Shuffler erwartungsgem nicht ganz gew hnlich. So wird eine AGA-Workbench unterst tzt, und mit Grafik- karten sollte es zumindest mit einem Register- (d.h. nicht Echtfarb-) Modus keine Probleme geben. Bitte ausprobieren. Au erdem - und jetzt kommt der Hammer - shuffled Shuffle den vordersten Screen nicht nur, son- dern restauriert ihn auf Wunsch auch wieder. Da seid Ihr platt, was? Modus/Mode: bestimmt den Shuffle-Modus. "Mischen/Shuffle" ist die Stan- dard-Einstellung. Hier wird der Screen nur geshuffled. Die beiden anderen funktionieren nur mit aktivierter "Blanker wechseln/Exchange Blankers"-Option (Hauptfenster), da der Blanker daf r wissen mu , wie lange er maximal blanken soll. "Mischen & Aufl sung / Shuffle & Restore" Shuffled die H lfte der Zeit, danach wird restauriert, also werden die Tiles wieder so verschoben, da alles wieder richtig wird. "Aufl sung/Restore" bringt den Screen zuerst (unsichtbar) so durcheinander, da nach der eingestellten Zeit der Screen wie der hergestellt ist. Danach wird restauriert. Geschw./Speed: bestimmt die Geschwindigkeit. Diese wird f r die Zeit- berechnungen (s.o.) mitber cksichtigt. Gitter/Grid: schaltet den 3D-Rahmen ein oder aus. Falls die Farben des Bildschirms berhaupt nicht passen (3D-Rahmen w rde bl aussehen) benutzt der Blanker nie einen Rahmen. Fehlermeldungen: "The "Shuffle & Restore" mode and the "Restore" mode can be only used if "Exchange Blanker" is activated." Diese Fehlermeldung will uns sagen, da es doch ein User probiert hat, diese Modi ohne "Blanker wechseln/Exchange Blankers" zu benutzen. CPU-Belastung: Niedrig. Speicherverbrauch:??? kB. Programmgr e:13 kB. (Der Speicherverbrauch von Shuffle h ngt sehr stark von der Aufl sung des zu "shufflenden" Screens und der Mode-Option ab, da hier etwas mehr Spei- cherplatz ben tigt wird.) @endnode @node b_skyline "Die Blanker in der bersicht - Skyline" @{FG Highlight}@{B}Skyline@{FG Filltext}@{UB} Von Aicke Schulz, Version 1. Na Ihr Hinterw ldler, wollt Ihr mal was anderes sehen als K he und Berge? Als Stadtmensch kann ich mir jetzt gar nicht so vorstellen, wie das auf dem Land abgeht. Zweiunddrei ig Einwohner, eine Schule, einen Lehrer, einen Briefkasten, eine Stra e, eine Telefonzelle, zwei Amigas? Oder habt Ihr etwa PC's? Doch bevor ich Euch nun ber die 20 Nachteile eines PC's aufkl re, sage ich noch etwas zu Skyline. Skyline stellt Hochh user dar, wie sie in richtig gro en St dten vorkommen. Weil es aber dunkel ist, sieht man sie nicht. Man sieht nur die Fenster, in denen noch Licht an ist. Die Helligkeitswerte f r die einzelnen Fenster werden ber eine quadratische Binominalsublimationsfunktion trianguliert, die Aicke in n chtelanger Kleinarbeit nach ihren Koeffizienten aufgel hatte. Dagegen wird der Mond nur auf einer billigen Parabel bewegt. Skyline geh rt zu den Blankern, deren voller Funktionsumfang nicht auf den ersten Blick ersichtlich ist. Deshalb solltet Ihr hier Duration ruhig ein- mal hochstellen, dann kommen die vielen Fassadentypen zum Vorschein. Die verschiedenen D cher kann man gleich bewundern. Mond-/Moonphase: Skyline stellt am Horizont einen Mond dar, der sich lang- sam ber den Screen bewegt. "Zufall/Random" l t den Zufall ber die Gr e der Sichel entscheiden, "Ein- stellung/Setting" macht die Gr e einstellbar (mittels des gleichnamigen Sliders darunter). Einst./Setting: Falls unter Moonphase "Einstellung/Setting" eingestellt ist, l t sich hiermit die Gr e der Mondsichel in Prozent einstellen. 100% entspricht einem Vollmond, 0% einem Neu- mond. Sternfarbe/ Starcolor: Die Sterne am Himmel lassen sich in ihrer Farbe beein- flussen. "Aus/Off" schaltet sie ganz aus, "Zufall/Random" l t den Computer w hlen. Anzahl/Number: Anzahl der Sterne. Y-Limit: gibt an, wie weit die Sterne nach unten gehen bzw. in welcher Bildschirmzeile sich der unterste Stern befinden darf. Himmel/Sky: schaltet zwischen verschieden Copper-Listen im Hinter- grund um. "Zufall/Random" ist wieder der Zufallsgenerator. Fehlermeldungen: siehe @{"AMOS-Errors",link amos_errors}. CPU-Belastung: Niedrig. Speicherverbrauch:200 kB. Programmgr e:32 kB. @endnode @node b_soccer "Die Blanker in der bersicht - Soccer" @{FG Highlight}@{B}Soccer@{FG Filltext}@{UB} Von Carsten Jahn, viele Spieler-Grafiken von Aicke Schulz; Version 1 Hier mal wieder eine echt innovative Idee: Fu ball in den Arbeitspausen hat wohl vielen gerade noch gefehlt. Was Bundesliga-Fans bestimmt begei- stert, wird wohl auch anderen (mich eingeschlossen...) viel Freude machen. Die kleinen Fu baller rennen, was das Zeug h lt (jedenfalls auf schnelle- ren Amigas), um die gegnerische Mannschaft fertigzumachen. Ab und zu f llt auch mal ein Tor, mangels Sound ist aber leider nicht viel von den Fans zu h ren. Und hier haben wir auch schon die Aufgabe f Euch da drau en: anfeuern, mitjubeln, ausrasten. Viel Spa damit. Wenn m glich (Speicher verf gbar) arbeitet Soccer mit Double Buffering. Aufstellung Wei /Rot / Line-up White/Red: hiermit stellt Ihr die Spieltaktik ein, nach der die kleinen Erdnuckel spielen. 1. Zahl: Spieler in der Abwehr, 2. Zahl: Spieler im Mittelfeld, 3. Zahl: Spieler im Sturm. Torwartsintelligenz/ Keeper intelligence: als ob irgendetwas im Computer intelligent w l t sich hier die Intelligenz der beiden Torw einstellen, was die Ergebnisse nat rlich fatal beeinflu CPU-Belastung: Hoch. Speicherverbrauch:378 kB. Programmgr e:45 kB. Bei Speichermangel:260 kB. @endnode @node b_stars "Die Blanker in der bersicht - Stars" @{FG Highlight}@{B}Stars@{FG Filltext}@{UB} Von Carsten Jahn, Version 2 Auch hier ein Blanker, der dem Beobachter den Eindruck gibt, r umlich in einem unendlichen Weltraum herumzufliegen. Auch hier ein paar Extras: re zuerst der R rtsgang zu nennen, den viele schon in anderen Star-Blankern vermi t haben werden. Der absolute Clou ist aber der Dreh- Effekt, der sich in H ufigkeit, Beschleunigung und Geschwindigkeit beeinflussen l t. Besonders der "Waschmaschinen-Effekt" (hohe Drehzahl bei niedriger Geschwindigkeit) l st immer wieder belkeit unter den Betrachtern aus... rrah! Fast schon be ngstigend wirken die Shift-Effekte: die Kamerafahrt durchs Sternenfeld ist dann erst kurvenreich. Diesen Blanker habe brigens optimiert wie keinen anderen. Besonders die Dreheffekte verlangsamen den Blanker kaum, und die Performance insgesamt ist schon ganz gut. Wie jeden anderen Blanker habe ich die Stars zwar in C geschrieben, aber mit Hilfe des Compiler-Assembler-Listings optimiert. Anzahl der Sterne/ Number of Stars: h.. Anzahl der Sterne? Normale Bewegungen/Normal Movements (Bewegungen auf der Z-Achse): Maximum: max. Fluggeschwindigkeit des Betrachters. Manimum: min. Fluggeschwindigkeit des Betrachters. Negative Zahlen lassen auch den R rtsgang zu. ndern/Changes: bestimmt, wie oft die Geschwindigkeit gewechselt wer- den soll. Start: Startgeschwindigkeit. Drehungen/Turns (Bewegungen UM die Z-Achse, Drehungen des Betrachters): Maximum: max. Drehmoment. Beschleunigung/ Acceleration: Beschleunigung der Drehung. ndern/Changes: bestimmt, wie oft die Drehrichtung wechselt. Start: Startgeschwindigkeit. Verschiebungen/Shifts (Bewegungen der X- und Y-Achse) Geschw./Speed: Dieser Wert legt fest, wie eng die Kurven sind. Gebrauch/Usage: bestimmt, wie oft der "Kurvenmodus" verwendet wird; 0 = nie, 10 = immer. X/Y: Hiermit wird definiert, ob sich die Verschiebungen nur auf eine Achse, beide oder gar keine beziegen. CPU-Belastung: Hoch. Speicherverbrauch:70 kB. Programmgr e:11 kB. @endnode @node b_softwarefailure "Die Blanker in der bersicht - SoftwareFailure" @{FG Highlight}@{B}SoftwareFailure@{FG Filltext}@{UB} Von Aicke Schulz, Version 1. Tipp, tipp; F10; Compiling; No Errors; Linking; Running: Blink-Blink-Blink. -Zap- "Software Failure - Press left mouse button to continue". Von erfolgreichen Programmieren empfohlen: der leichte Absturz f Zwischendurch. In H llen ist auch das Sechserpack geeignet. F r An- wender, die nur ausgereifte Software benutzen, bietet sich aber Software- Failure f r den t glichen Gebrauch an. SoftwareFailure simuliert den komplexen Ablauf eines Absturzes nur grafisch, was aber den Vorteil hat, man nach dem Blanken weiterarbeiten kann. berraschungseffekt nach den Arbeitspausen ist immer wieder t dlich! Damit sich die Alert-Box aber nicht einbrennt, und damit Nervenschwache nicht jedesmal einen Infarkt bekommen, wird der SoftwareFailure noch in drei verschiedenen Modi animiert. Effekt/Effect: Mit Effekt kann gew hlt werden, was nach einer gewissen Zeit des Blinkens mit der Alert-Box geschehen soll: "Zerflie en/Melt" l t sie langsam zerflie en, "Springen/ Bounce" l t sie auf und ab h pfen und "Crazy" bewegt die einzelnen Buchstaben. Warten/Wait: Hier wird die gewisse Zeit (s.o.) bestimmt, in Sekunden. Fehlermeldungen: siehe @{"AMOS-Errors",link amos_errors}. CPU-Belastung: Niedrig. Speicherverbrauch:150 kB. Programmgr e:29 kB. @endnode @node b_thunder "Die Blanker in der bersicht - Thunder" @{FG Highlight}@{B}Thunder@{FG Filltext}@{UB} Von Aicke Schulz, Version 1. Blitz und Donner im Amiga! Mit realistischem Sound. Wenn es drau en kalt und Winter ist (kann man das so sagen?...), dann kommt dieser Blanker ge- rade richtig. Die Blitze zucken nur so ber den Screen, da man denkt, es hat den Monitor zerbr selt. Au erdem kann man sehr gut die bertra- gungsgeschwindigkeit von Wellen mit unterschiedlicher Wellenl nge in der Luft erkennen: w hrend man den Blitz fast sofort sieht, kommt das Ge- usch erst sp ter. Wie lange die Zeitspanne zwischen Blitz und Donner ist, h ngt also von der Entfernung des Unwetters ab, die man mit "Distanz/ Distance" einstellen kann. Einschl ge/Flash Interval: Mit dieser Einstellung wird bestimmt, wie oft die Blitze einschlagen. Es sind jeweils Zeit- spannen angegeben, die Blitze werden dann in der gew hlten Zeitspanne abgeblitzt. Distanz/Distance: Gibt die Entfernung des Gewitters in Metern an und bestimmt damit die Zeitspanne zwischen Blitz und Donner. Toneffekt/Sound: Hiermit kann man die Ger usche abschalten, falls man das mit den Wellenl ngen noch nicht ganz verstanden hat. Fehlermeldungen: siehe @{"AMOS-Errors",link amos_errors}. CPU-Belastung: Niedrig. Speicherverbrauch:185 kB. Programmgr e:32 kB. @endnode @node b_waves "Die Blanker in der bersicht - Waves" @{FG Highlight}@{B}Waves@{FG Filltext}@{UB} Von Carsten Jahn, viele Farbpaletten von Aicke Schulz; Version 1. Dieser Blanker erzeugt Wellen, die so aussehen, als w ren sie einem ganz genialen Algorithmus entsprungen. Tats chlich wird nur ein einfacher Trick angewandt, wie er in manchen Demos zu finden ist. Zum besseren Ver- ndnis und zum allgemeinen Aha-Effekt will ich ihn erl utern: Zuerst wird (im Hintergrund) mit 1, 2 oder 3 Pixel dicken Querstreifen ein Farb- verlauf auf den Screen gezeichnet. Dann kommt eine Sinus-Funktion daher, die aus den Streifen eine Welle macht - hoch, runter, hoch runter, ... Weil das Ergebnis noch eindeutig als Sinus-Funktion erkennbar w re, wird jede Bildzeile noch um eine weitere Sinus-Funktion nach links oder rechts verschoben. Jetzt bekommt der Screen seine Farben, die kontinuierlich durchlaufen. Zur Steigerung des beliebten W rg-Effekts wird der Screen, der Anfangs mit bergr ffnet wurde, anhand zweier Sinus-Funktionen (ach ja..) nach links/rechts und oben/unten verschoben. Nat rlich kann man keine gew hnliche Farbpalette nehmen, sie mu echt terrorm ig 'rein- hauen. Da bleibt kein Teppich trocken -schluck-. Obwohl auch bei diesem Blanker eine Duration-Einstellung bis 30 min. glich ist, empfehlen wir aus gesundheitlichen Gr nden nicht mehr als 6 Minuten. Ob die Krankenkassen f r Folgesch den zahlen, ist uns nicht bekannt. Nebenwirkungen und Gegenanzeigen bitte melden. Das Prefs-Fenster ist in zwei Bereiche aufgeteilt. Links findet Ihr die Farbpaletten. Waves w hlt eine aus, bei der das H kchen gesetzt ist. Wer hinterh ltigerweise alle H kchen l scht, wird mit einer Zufallspalette nicht unter 32 Farben bestraft. Auf der rechten Seite seht Ihr die Ein- stellungen zum Zeichnen der Waves: Wellengr e/WaveSize: beeinflu t die gesamt-Dicke der Waves. XWellen/XWaves: bestimmt die Breite der Waves. Kleiner Wert = breite Waves. YWellen/YWaves: bestimmt die H he der Waves. Kleiner Wert = hohe Waves. XGr e/XSize: ist der Maximalausschlag der horizontalen Sinus- Funktion. YGr e/YSize: ist der Maximalausschlag der vertikalen Sinus- Funktion. XGeschw./XSpeed: legt fest, wie schnell sich der Screen in X-Richtung bewegt. YGeschw./YSpeed: legt fest, wie schnell sich der Screen in Y-Richtung bewegt. Da jetzt sicher nicht jeder Parameter sonnenklar ist (irgendwie kann man die Waves ja auch nicht beschreiben) rate ich zum gr ndlichen Auspro- bieren. brigens sind manche Farbpaletten bewu t NICHT sch n, sondern dienen dem Abschrecken von diversen Haustieren. Denn Vogelsch***e auf der Tastatur ist eine recht unangenehme Sache; Katzen haaren alles voll und Hunde lutschen glatt die Leertaste weg. Also Vorsicht! brigen halte ich gar nichts von Pa wortprogrammen, die den Computer vor Fehleingaben durch ber alles trampelnde Katzen sch tzen. Ein Pa wort h lt doch keine Katze davon ab, alles zu verw sten!) CPU-Belastung: Niedrig. Speicherverbrauch:212 kB. Programmgr e:14 kB. @endnode @node b_worldtime "Die Blanker in der bersicht - Worldtime" @{FG Highlight}@{B}Worldtime@{FG Filltext}@{UB} Von Aicke Schulz, Version 1. Wie h ngt man eine Weltkarte auf, ohne sich die Finger am Kartenst zu klemmen? Ganz einfach: entweder man l t die Karte weg und benutzt den Amiga (Buuuh) oder man h ngt die Karte mit dem NEUEN, GROSSEN, PRAKTISCHEN, PASSGENAUEN @{B}SCHLONZ-Kartenaufh ngehandschuh@{UB} auf! (Yeah). Der @{B}Schlonz-Arbeitshandschuh@{UB} wurde EXTRA F R SOLCHE AUFGABEN ENTWICKELT und bietet OPTIMALEN TRAGEKOMFORT. Wir haben uns in einer Berliner Droge- riefiliale umgesehen. Ah, da ist ja schon der erste Kunde. Interessiert bleibt er vor dem @{B}Schlonz@{UB}-Warensortiment stehen. Eine FREUNDLICHE Ver- uferin hilft ihm sogleich: "F r welche Aufgabe ben tigen Sie denn Ihren nftigen @{B}Schlonz@{UB}-Qualit tshandschuh? Ich habe doch gleich gemerkt, da Sie sich SPONTAN f r eines der @{B}Schlonz@{UB}-Produkte entschieden haben!" - "Ja, ein @{B}Schlonz@{UB}-Produkt wollte ich schon kaufen, da wei ich schlie lich, da ich QUALTIT T bekomme. Aber spontan ist meine Entscheidung nicht, mein NACHBAR hat mir @{B}SCHLONZ@{UB} EMPFOHLEN. Ich suche einen @{B}Schlonz@{UB} f r's Karten- ngen. Wo ist der nur, f hren Sie den etwa nicht?" - "SELBSTVER- NDLICH f hren wir das gesamten @{B}Schlonz@{UB}-Sortiment. Der zum Kar- tenaufh ngen ist im Moment DER RENNER. Welche Gr e haben Sie denn?" - "XL." - "Flupp, da ist er schon. Wollen Sie GR N oder ROT?" - "Tjaaa, schwere Frage. Ich glaube, zu den Karten pa t der gr ne @{B}Schlonz@{UB} am besten." - "Gute Wahl. Dieser @{B}Schlonz@{UB} wird ihnen noch SEHR LANGE Freude be- reiten. Auf Wiedersehen!" F r die User, denen die 2,5m x 1.7m - Karten zu bersichtlich sind, gibt's aber zum Gl ck noch andere Alternativen zu unserem @{B}Schlonz@{UB}-Schrott. Einfach Worldtime starten. Als kleiner Gag mit GROSSER Wirkung zeigt der @{B}Amiga@{UB} auch noch die Uhrzeiten in den entlegensten dten an. Reihenfolge/Order: "Random" zeigt die St dte nach dem Zufallsprinzip an, "One after another" in alphabetischer Reihenfolge. Warten/Wait: bestimmt, wie lange eine Stadt angezeigt wird (in Se- kunden). Stunden, Minuten, Hours und Minutes: ver ndert die Zeitverschiebung geben ber der MEZ. F r Deutschland m t Ihr 0 und 0 einstellen, weil sich Deutschland voll in Mitteleuropa befindet. Sprache/Language: Hiermit kann man das Datumsformat umschalten. F r Deutschland m t Ihr "Deutsch" einstellen. Fehlermeldungen: siehe @{"AMOS-Errors",link amos_errors}. CPU-Belastung: Niedrig. Speicherverbrauch:290 kB. Programmgr e:51 kB. @endnode @node errors "Fehler m ssen sein." Jeder, der auch nur ein noch so kleines Programm in einer nicht-BASIC- Sprache geschrieben hat, wei , was beim Programmlauf alles falsch gehen kann. Praktisch jede Funktion des Betriebssystems liefert einen R gabewert, der dann eventuell signalisiert, da kein Ergebnis vorliegt. Und ein korrektes Programm soll schlie lich mehr ausgeben als "Fehler: Programmabbruch." Und bei Madhouse k nnen zus tzlich die Blanker einen Fehler zur cklie- fern, der dann von Madhouse angezeigt werden mu Tritt ein Fehler bei einem Blanker auf, und er wurde im BlankerPrefs- Fenster gestartet, zeigt Madhouse den Fehler unten im Blanker-Prefs- Fenster an, welches daf r "ausgeklappt" wird. Stellt aber der Blanker einen Fehler fest, nachdem er durch Madhouse gestartet wurde (nach Ablauf der Zeitspanne), merkt sich Madhouse erst den Fehler, und ruft ggf. einen anderen Blanker auf. Ist keiner der ausgew hlten mehr brig (oder ben tigen die verbliebenen im Moment zuviel CPU-Performance, siehe @{"Advanced Options Fenster, 4.", link adv_op}) wird nur ein schwarzer Bildschirm angezeigt. Nach Abbruch eines Blankers / des schwarzen Bildschirms mit Maus oder Tastatur und evtl. Eingabe des Pass- worts wird dem erstaunten Benutzer die @{B}Madhouse-ErrorList@{UB} pr sentiert. Hier werden alle aufgetretenen Fehler gelistet. Verlassen wird die Liste mit dem Schlie gadget. Zu den Blanker-spezifischen Fehlern, die nichts mit so profanen Dingen wie "Out of memory", "Couldn't open Screen/Window" (beide Fehler sind das Resultat von zuwenig Speicher) zu tun haben, findet sich die Erl uterung in @{"Alle Blanker in der bersicht", link blankers}. In diesem Kapitel m chte ich aber noch die Fehler von Madhouse darlegen, die nicht sofort verst ndlich sind (also lasse ich die "Cannot open Win- dow"- und "Couldn't write file"-Fehler weg. Wenn der MadhouseConfigEd oder Madhouse selbst einen Fehler anzeigt, tut es das mit einem Fenster auf der Workbench, welches ein Abort-Gadget besitzt. Um das gleich klarzustellen: Dieses Fenster ist ein Easy-Request! Wer mit der Bedienung des Gadgets nicht ganz klarkommt, der darf sich ruhig fragen, wie wohl ein Difficult-Request funktioniert... In beiden F llen wird der Fehlertext angezeigt. Uuuund jetzt geht's los: @{B} Bitte einen KOMPLETTEN Pfad ausw hlen,... Please select a COMPLETE path,...@{UB} r bestimmte Spezialit ten (Buffering) ben tigt Madhouse den Namen der Diskette/Festplattenpartition, auf der sich die Blanker befinden. Das liegt ganz einfach daran, da man nicht abfragen kann, ob z.B. "DF0:" oder "//Blankers" gerade im Laufwerk liegt... Das geht nur mit Pfaden wie "MadhouseDisk:" oder "MadhouseDisk:Blankers". Also bitte etwas entsprechen- des im Path-Gadget des Hauptfensters eintragen. @{B} Die "gadget"-Datei von xy enth lt keinen BlankerInfo-Chunk! BlankerInfo-Chunk does not exist!@{UB} Die Datei "gadget" des betreffenden Blankers (in seinem Verzeichnis) ist fehlerhaft; die BlankerInfo-Informationen fehlen. Madhouse kann nicht lesen, ob der Blanker viel CPU-Performance benutzt oder nicht. @{B} Unbekanntes Makro: "xx"! Unknown macro: xx@{UB} In der "gadget"-Datei des aufgerufenen Blankers befindet sich ein Makro namens xx. Dieses ist leider nicht existent. @{B} Couldn't get a lock on this directory!@{UB} Vermutlich wurde im Path-Gadget oder mit dem FileRequester ein falscher Pfad eingegeben. Oder ein Diskettenkopierer hat die gesamte Disk gesperrt, so da Madhouse nicht darauf zugreifen kann. @{B} Konnte das Verzeichnis "RAM:Madhouse_Storage" nicht anlegen. Couldn't create the subdirectory "Ram:..."@{UB} r verschiedene Zwecke wird ein Unterverzeichnis "Madhouse_Storage" in der RAM: - Disk angelegt. Das geht aber nur, wenn 1. Ram: berhaupt gemounted ist (Normalzustand) und wenn 2. Madhouse nicht bereits gestartet wurde. So wird auch eine Doppelt-Inkarnation von Madhouse verhindert. @{B} Madhouse wurde doppelt gestart! Soll es beendet werden? You started Madhouse the second time. Do you want to remove it?@{UB} So ein Schlingel: Madhouse doppelt gestartet und gedacht, jetzt kommt alles durcheinander, oder was? Nur, damit Ihr im Bilde seid: - Das Madhouse, da Ihr eben gestartet habt, hat sich sowieso schon beendet. - Das Madhouse, da Ihr vorhin gestartet habt, hat hinterh ltigerweise da- von erfahren. Und nun? Naja, der Doppelstart ist eine M glichkeit, Mad- house loszuwerden. Einfach den Requester mit "Remove Madhouse" beantwor- ten, und tsch . "Do nothing" sieht den Doppelstart eher als einen Un- fall an und macht so weiter wie zuvor. @{B} Die amos.library wurde nicht gefunden... No amos.library@{UB} Selbstredend ben tigt Madhouse nicht die amos.library, um Himmels Willen! Madhouse wollte die amos.library von LIBS:amos.library in sein Storage- Verzeichnis auf der Ram:-Disk kopieren. Damit die Blanker vollen Zugriff darauf haben. Die Datei LIBS:amos.library war aber nicht vorhanden, was zur Folge hat, da der Buffering-Modus ausgeschaltet wird. Jetzt solltet Ihr lieber keine AMOS-Blanker (die von Aicke, siehe Blanker-Teil) starten, denn die werden die amos-lib erst recht nicht finden k nnen, und dann ist . Madhouse wurde offenbar falsch installiert. @{B} Konnte die "gadget"-Datei des Blankers "xy" nicht laden! Couldn't load the "gadget"-file!@{UB} Die gadget-Datei wird ben tigt, um das Fenster zu ffnen. Sie ist nicht vorhanden. Diese Datei mu ebenfalls vorhanden sein, damit Madhouse beim Einlesen des Blankers-Verzeichnisses Informationen zu diesem Blanker erhalten kann. @{B} Probleme mit dem Pa Problems with your password@{UB} Dieser Fehler erscheint, falls es jemandem nicht m glich war, sein Pa wort bei der Sicherungsabfrage einzutippen. Das kann jetzt verschiedene nde haben... Angenommen, Ihr habt es vergessen (nach 2 Sekunden...), dann sollte ein anderes gew hlt werden. War der Eingabebildschirm auf einmal weg? Tjaa, wer hat denn da , , oder hnliches gedr ckt? Aus Sicherheitsgr nden wird bei diesen Qualifiern abgebrochen (stimmt wirklich; damit man NICHT einen Trick anwenden kann, den ich aber trotzdem nicht verrate - doppelt sicher!). Die Ziffern und Sonderzeichen, die nicht mit o.a. Zeichen erreicht werden m ssen, gehen aber. @{B} Madhouse ben tigt einen Stack von mindestens 4.096 Bytes! ... Need a stack minimum of 4.096!@{UB} Der Stack ist ein Bereich im Speicher des Amiga, der f r jedes Programm bei seinem Start von AmigaDOS reserviert wird. Das gestartete Programm hat keinen Einflu auf dessen Gr e, weil er kurz vor dem Start des Programms eingerichtet wird. Die ben tigte Gr e von 4096 Bytes ist bei Amiga-Programmen eigentlich der Standard, deshalb sollte man Madhouse von berall her aufrufen nnen. Falls dieser Fehler trotzdem auftritt, erkl re ich Euch nun, wie man die verschiedenen Programme doch dazu berreden kann, Madhouse korrekt zu starten. Die Workench merkt sich die Stack-Gr e der Programme in ihrem Icon. Also Madhouse 1x anklicken und im "Icon"- bzw. "Piktogramm"- Men Workbench "Information" ausw hlen. Ein Fenster ffnet sich, in dem sich auch ein Number-Gadget namens "Stack:" befindet. Hier 4096 eintragen und mit "Save" bzw. "Speichern" verlassen. Die Shell startet ihre Programme immer mit dem aktuellen Stack, der r jedes Shell-Fenster variieren kann. Also Shell ffnen, "stack 4096" eingeben und Madhouse mit z.B. "run Work:Madhouse/Madhouse" starten. Wer Madhouse mit dem Toolmanager startet, der findet im ndere Programm- Objekt-Fenster auch hier ein Stack-Gadget. @{B} Bug #1 in program!@{UB} Bitte schreibt mir, wenn dieser Fehler auftritt!! @{B} Auf deiner 1.3-Sch ssel l uft Madhouse nicht!@{UB} -Schluck!- ist dies etwa ein 1.x-Amiga?! Ey Leute, es gibt doch wirklich f r JEDES Amiga-Modell eine Kickstart- stung auf 2.0!! 93% aller PD-Software, die ich benutze, braucht OS 2.0! Und jedes 3. kommerzielle Programm auch! Wie kann man es auf dem Amiga ohne OS 2.0 aushalten, wenn man nicht nur spielt? OS 2.0 ist soooo toll und vergleichsweise billig! r pure Einsteiger, die vor ein paar Monaten ihren Amiga gekauft haben: OS 2.0 hei t das Betriebssystem, und Euch hat man einen Amiga ange- dreht, der nicht mal auf dem Stand von vor 5 Jahren ist. Besorgt Euch also das Upgrade. OS hat nichts mit IBM zu tun :-> sondern ist von Commo- dore. Wer meint, OS 2.0 zu haben und bekommt diesen Fehler, der hat ein echtes Problem... Wer gerade losrennen will, um OS 2.0 zu kaufen, der kann sich auch gleich das aktuellere 3.1 besorgen. @{B} Die "gadget"-Datei dieses Blankers kann nicht gelesen werden. Dazu wird eine neuere Madhouse-Version ben tigt. Cannot read the "gadget"-file of this blanker! (You need a newer Version of Madhouse)@{UB} Die erste Zeile der "gadget"-Datei dieses Blankers hat nicht den Inhalt "Madhouse, Blankerwindow-Def V1". Entweder Schreibfehler oder Eure Mad- house-Version ist berholt. (Ich denke nicht, da ich am Dateiaufbau mal ndern werde. Wenn neue Chunks hinzukommen, ist das noch lange kein Grund, da die alten Files inkompatibel werden m ssen - dazu habe ich mir das ja extra so ausgedacht.) @{B} File mismatch: Chunk "Dimensions" must be the first chunk!@{UB} Dieser Chunk mu der vor allen anderen Chunks stehen! @{B} BlankerPrefs-window too big for this screen!@{UB} Die Workbench ist zu klein f r diese Prefs-Fenster. Oder Schreibfehler in der "gadget"-Datei dieses Blankers (Stichwort "CHUNK:WINDOW"). @{B} Enter a higher value in "CHUNK:DIMENSIONS" - Gadgets!@{UB} Nicht nachdenken, ... machen! @{B} Der Chunk MUI-PREFSORDER ist falsch. Wrong Statements in CHUNK:MUI-PREFSORDER.@{UB} Im Chunk "MUI-PREFSORDER" stehen falsche Sachen drin. @{B} Konnte den Config-Editor nicht erreichen. Couldn't access the Config-Editor.@{UB} Madhouse wollte den MadhouseConfigEd starten, also das Programm, mit dem man die Madhouse-Einstellungen ndern kann. Damit Madhouse den ConfigEd starten kann, mu chst Madhouse wieder beendet werden, da die Pfad- angabe zum ConfigEd nur beim Programmstart ausgelesen wird. Um Madhouse zu beenden, mu man zun chst wissen, ob es berhaupt l - Wenn Madhouse gerade erst seit wenigen Sekunden l uft und man nicht "Madhouse" im Tools/Hilfsmittel-Men aufgerufen hat, und diese Meldung erscheint, dann mu sich Madhouse sowieso sofort nach Best tigung des Requesters beenden, da es ohne Einstellungen keine Chance hat. - Wurde diese Meldung durch die Auswahl von "Madhouse" im Tools/Hilfs- mittelmen "provoziert", dann lagen offenbar schon die korrekten Ein- stellungen vor. Madhouse mu nun beendet werden. Dies kann ber das Exchange-Programm oder durch den erneuten Programmstart und an- schlie endem "Remove Madhouse" geschehen. Ob sich Madhouse nach diesem Requester beenden mu , ist auch dem Requester- Text zu entnehmen, der auf diese Situation angepa t wird. Ob Madhouse gerade l uft oder nicht, l t sich jederzeit einfach durch einen Blick ins Tools-Men feststellen. Nun sollte man im ToolType "CONFIGED" von Madhouse den Pfad und Namen des ConfigEds eintragen. Will man Madhouse nicht mit der Workbench, sondern von der Shell starten, so wird der ConfigEd im Programmverzeichnis von Madhouse angenommen. In diesem Fall k nnen die ToolTypes meines Wissens nach nicht ausgelesen werden. @{B} Der MadhouseConfigEd kann nur von Madhouse selbst gestartet werden.@{UB} Klare Sache: der ConfigEd l t sich nur ber das Hilfsmittel- / Tools-Men der Workbench starten, nicht direkt durch den User. Diese Einschr nkung te sein, da Madhouse und der ConfigEd beide das Madhouse_Storage- Verzeichnis in der Ram-Disk benutzen. Wenn beide gleichzeitig laufen oder Madhouse nicht gestartet wurde, kann es zu Kollisionen kommen. @endnode @node amos_errors "Die AMOS-Pro-Fehlernummern und ihre Bedeutung" Dieses Kapitel beschreibt die Fehlernummern, die von den AMOS-Blankern angezeigt werden, wenn etwas nicht klappte. (Dieses Kapitel kann nur aus den Blanker-Beschreibungen der AMOS-Blanker abgerufen werden, des- halb k nnt Ihr Euch jetzt sicher sein, da der Blanker ein AMOS-Blanker ist.) Zuerst mu noch gesagt werden, da ein bestimmter Fehler nicht als Nummer, sondern als Klartext in der Errorlist / im BlankerPrefs-Fenster angezeigt wird. Er lautet "@{B}Out of memory.@{UB}" und signalisiert, da nicht ge- gend freier Speicher zur Verf gung stand, um den Blanker zu starten. In den anderen AMOS-Fehlern steht etwas von einer AMOSPro-Errornumber, und diese Numbers bekommen gleich eine Bedeutung. Da jedoch das AMOS-Pro-Hand- buch 13 Seiten ber dieses Thema enth lt, z hle ich hier nur die Fehler auf, die sich von Euch beheben lassen. @{B}Nummer Beschreibung@{UB} @{FG Highlight} 30 Falsches IFF-Format.@{FG Filltext} Vielleicht konnte man diesem Blanker den Dateinamen eines Bildes bergeben, das er laden sollte. Diese Bilddatei ist jedoch in Wirklichkeit eine Datei anderen Typs. @{FG Highlight}187 Kann die med.library nicht laden.@{FG Filltext} Dieser Blanker wollte wohl Musik abspielen, und ohne med.library geht das (fast) nicht. Keiner von Aickes AMOS-Blankern ben tigt diese Library, weshalb sie auch nicht in Madhouse enthalten ist. @{FG Highlight} 32 Das IFF-Bild pa t nicht auf den Bildschirm.@{FG Filltext} Eigentlich ein Fehler wie Nummer 30, an Eurem Bild stimmt etwas nicht. @{FG Highlight} 86 Ger t (=Diskette) nicht verf gbar.@{FG Filltext} Auch diese Fehlermeldung kann nur von einem Blanker kommen, der die Eingabe eines Dateinamens erlaubt. Ohne Buffering darf man hier den gesamten Pfad eingeben, weil dann die Diskette (h chstwahrscheinlich die Festplatte) immer "eingelegt" sein mu . Mit Buffering mu man seine Datei in das Un- terverzeichnis des Blankers kopieren und nur den Dateinamen ange- ben. Wenn das so geschehen ist, arbeitet der Blanker nicht nach der Madhouse-Konvention aus @{"Das Blanker-Unterverzeichnis", link p_dir }. @{FG Highlight}101 Diskettenfehler.@{FG Filltext} Hier ist wohl die Diskette/Festplatte mehr oder weniger kaputt. @{FG Highlight} 88 Diskette voll.@{FG Filltext} Dieser Fehler kann eigentlich nur entstehen, wenn ein AMOS-Blanker gerade seine Fehlermeldung in RAM:Madhouse_Storage ab- legen wollte. Der Speicher ist wohl so knapp, da selbst eine kleine Datei nicht mehr in den Speicher pa t. Vermutlich ist der Speicher dann auch so knapp, da Madhouse diesen Fehler gar nicht anzeigen kann. Und dieser Fehler kann ja auch nur ber die RAM:-Disk an Mad- house bermittelt werden. Also ist DAS hier der Fehler und nicht irgendein anderer, der diesen Fehler ausl ste. Ein Fehler, der nur beim Schreiben eines anderen Fehlers auftritt, mu hier eigentlich nicht mehr erw hnt werden. So einen Fehler darf man ja eigentlich noch nicht einmal abfragen, oder habt Ihr eine Ahnung, was passiert, wenn beim Schreiben des Fehlers ein Schreibfehler auftritt, der dann auch geschrieben wird und sicherlich seinerseits den n chsten Schreibfehler verursacht?! Ach, verge t es. Tats chlich gibt es auch hier den Sonderfall 48d (siehe Problem- kapitel) mit der statischen Ram-Disk als RAM:. Falls Eurer Stat-Ram also gerade das letzte Byte allegegangen ist, (bei den Typen, bei denen man den max. Speicherverbrauch angeben kann/mu ), dann ist ist dieser Fehler auch hier m glich. @{FG Highlight} 81 Datei nicht gefunden.@{FG Filltext} Entweder habt Ihr eine Datei gel scht, die der Blanker unbedingt ben tigt, oder Ihr habt Euch bei einem eigenen Dateinamen vertippt. @{FG Highlight} 44 Font (Schriftfamilie) nicht verf gbar.@{FG Filltext} @{FG Highlight} 31 IFF-Kompressionsalgorithmus unbekannt.@{FG Filltext} Abhilfe: Die eigene IFF-Datei in ein Malprogramm laden und gleich wieder unter demselben Namen abspeichern. Diesen Vorgang mit allen zur Verf gung stehenden Mal- programmen und Bildbearbeitungen wiederholen, bis der Fehler nicht mehr auftritt. @{FG Highlight} 82 Buchstabensalat im Dateinamen.@{FG Filltext} Da hat sich einer m chtig vertippt, denn dieser Dateiname pa t noch nicht einmal von Format her zu AmigaDOS. (Beispiel: "Work:Bla:Hallo") @{FG Highlight} 93 Keine Diskette im Laufwerk.@{FG Filltext} Siehe Fehler 86. @{FG Highlight} 92 Keine AmigaDOS-Diskette.@{FG Filltext} Wirkung wie 101. @{FG Highlight}186 Kein Tracker-Modul.@{FG Filltext} Hier konnte man wohl den Dateinamen eines Noise- Tracker-kompatiblen Musikmoduls angeben. Diese Datei ist nicht kom- patibel. @{FG Highlight} 0 Kein freier Raum im Stack mehr.@{FG Filltext} Abhilfe: in einem Editor (z.B. c:ed) die "gadget"-Datei laden, die im Verzeichnis des Blankers steht, der den Fehler verursacht hat. In der Datei nach einem Text "CHUNK:BLANKERINFO" suchen. Vier Zeilen darunter befindet sich eine gro e Zahl, z.B. 5000. Daraus jetzt z.B. 9000 oder mehr machen. Die ver nderte Datei abspeichern und das Madhouse-Hauptfenster ffnen. Jetzt in das Path-Gadget klicken und dr cken. Nun sollte der Blanker funktionieren, wenn nicht, die Zahl noch gr w hlen. Ein Versuch mit absichtlich zu niedrigem Stack zeigte, da der Blan- ker zwar tolle Probleme (recoverable Alert, Mauszeiger bleibt ste- hen) verursacht, aber nicht diesen Fehler erzeugt. Trotzdem ist dann die Vorgehensweise richtig, um einen eigenen Blanker zum Laufen zu bringen. @endnode @node buffering "Alles ber die Buffering-Option!" Da h ngt nun so ein kleiner Haken im Advanced-(Options-Fenster) rum... was kann der schon machen? Und wer ihn einfach ausprobiert, wird auch kaum etwas merken. Doch der unscheinbare Haken ist ein starker Vorteil r jeden, der die Blanker auf eine Diskette installiert hat. Denn man kann eine Diskette bekanntlich aus dem Laufwerk nehmen. Wenn dann ein Programm darauf zugreift, erscheint ein Requester, der Euch freundlich auffordert, diese Disk einzulegen. W hrenddessen ist das aufrufende Programm praktisch "leblos". Das Dilemma: Den meisten Programmen ist es egal, ob sie ihre Disk nun gleich oder ein paar St ndchen sp ter kriegen. Madhouse nicht, denn wenn geblankt werden mu , dann gleich. Also wird sicherheitshalber ein Blanker in die Ram:-Disk kopiert, wo er auch erreichbar ist, wenn die Disk nicht da ist. Das macht Madhouse nur bei eingeschaltetem Buffering. Ist die Disk aber doch da, kann ein Blanker von dort nachgeladen werden, falls der Blanker im Speicher schon benutzt wurde. Wenn die Disk aber nicht da ist, geblankt wurde, der User abbricht, evtl. ein Pa wort eingegeben wird, dann ggf. die Fehlermel- dungen der Blanker in der Errorlist vom User best tigt wurden, die Disk immer noch nicht da ist, im Advanced-Options-Fenster "Nach Disk fragen / Ask for Disk" gew hlt wurde UND wenn der Speicher dazu reicht, wird noch ein kleines Fenster auf der Workbench oder dem aktuellen PublicScreen ffnet, welches auf diesen Zustand aufmerksam macht... Zus tzlich wird die amos.library auf die RAM:-Disk kopiert, damit die AMOS-Blanker eine haben, wenn sie sie brauchen. Wenn ein Blanker es erlaubt, einen Dateinamen einzustellen (ist momen- tan noch nicht der Fall) dann @{B}m ssen@{UB} Disketten-User diese Datei in das Blankerunterverzeichnis kopieren, weil sie nur dort ggf. in die Ram:-Disk gerettet wird. Im Stringgadget dieses BlankerPrefs-Fensters mu dann nur der Dateiname eingetragen werden, ohne Pfad. Bei einer Eingabe von FileXY sucht der Blanker also nach RAM:Madhouse_Storage/FileXY oder Work:Madhouse/Blankers/NiceBlanker/FileXY, je nachdem, von wo er gestartet wurde. Aber das ist - wie gesagt - momentan noch unwichtig, da im Moment keine Blanker existieren, die nach Dateinamen fragen. @endnode @node reference "Der Referenz-Teil" Dieser Teil der Madhouse-Anleitung dient dem Nachschlagen der Gadgets einzelner Fenster. @{B}Ohne MUI:@{UB} @{" Das Hauptfenster ",link ref_mainwin} @{" Das BlankerPrefs-Fenster ",link ref_editPrefs} @{" Das Advanced-Options-Fenster ",link adv_op} @{" Die Error-List ",link errors} @{" Das AskForDisk-Fenster ",link ref_littlewin} @{B}Mit MUI:@{UB} @{" Das Hauptfenster ",link ref_muimainwin} @{" Das BlankerPrefs-Fenster ",link ref_editPrefs} @{" Die Error-List ",link errors} @{" Das AskForDisk-Fenster ",link ref_littlewin} @{B}Tooltypes@{UB} @{" CONFIGED ",link tt_configed} @{" QUIETQUIT ",link tt_quietquit} @endnode @node tt_configed "Referenz: Tooltypes - CONFIGED" CONFIGED Der komplette Pfad des MadhouseConfigEd mu direkt hinter dem "=" ange- geben werden. Beispiel: CONFIGED=Work:Madhouse/MadhouseConfigEd Neben dem "=" d rfen keine Leerzeichen stehen. @endnode @node tt_quietquit "Referenz: Tooltypes - QUIETQUIT" QUIETQUIT Wenn dieser Tooltype eingeschaltet ist, nervt Euch Madhouse nicht mit einem Sicherungsrequester, wenn Ihr es durch erneuten Start beenden wolltet. Wer den Requester haben will, mu diesen Tooltype entfernen oder in Klammern setzen. @endnode @node ref_mainwin "Referenz: Das Hauptfenster" @{B}I. Wie man dieses Fenster ffnet.@{UB} Um dieses Fenster zu ffnen, mu man zuerst auf die Workbench klicken und dann deren Tools- (Hilfsmittel-) Men hlen. Darin befindet sich der Ein- trag "Madhouse". Nach dessen Answahl ffnet sich dann das Fenster. @{B}II. Die Gadgets@{UB} Witzigerweise wird hier jedes Gadget durch ein Gadget repr sentiert. Bei Anklick Infos. Edit @{" Prefs... ",link main_edit} @{" Listengadget ",link main_list} Pfad/Path @{"Work:Tools/Ma",link main_path} @{" Weitere Optionen/Advanced Options ",link main_advOpt} Zeit/Time @{" | ",link main_time} @{" ",link main_changeBl} Blanker wechseln/ Exchange Blankers @{" Speichern/Save ",link main_save} @{" Benutzen/Use ",link main_use} @{" Entfernen/Remove ",link main_remove} @{" Info ",link main_info} @{B}III. Wie man die Einstellungen speichert.@{UB} Auf "Sichern/Save" klicken. @{B}IV. Wie man das Fenster schlie t.@{UB} Dazu dienen die Gadgets "Speichern/Save" und "Benutzen/Use". Achtung: solange diese Fenster, das Advanced-Options-Fenster oder die Error-List offen ist, wird Madhouse nach Ablauf der Zeit keinen Blanker starten. @endnode ## The Gadgets @node main_edit "Referenz - Hauptfenster: Edit" Dieses Gadget beeinflu t nur die Liste. Man kann hier zwischen der Funktion der Liste umschalten. Es gibt zwei M glichkeiten: "Selection/Aus- wahl" schaltet die Liste in den Blanker-Auswahl-Modus. Jetzt kann man w len, welche Blanker gezeigt werden sollen, wenn die Zeit nach einer Schaffensphase um ist. Ist "Einstellung/Prefs..." aktiv, bewirkt ein Klick in die Blanker-Liste ffnen das BlankerPrefs-Fensters f r diesen Blanker. Ist das Gadget schraffiert und damit unbrauchbar gemacht, dann ist ein falscher Pfad eingestellt. Weitere Infos in @{"Der Workshop", link workshop}, Punkt 5. @endnode @node main_list "Referenz - Hauptfenster: Das Listengadget" Die Liste ist mit dem Edit-Gadget verbunden. Wenn im Edit-Gadget "Einstel- lung/Prefs..." eingestellt ist, zeigt die Liste die Namen aller Blanker. Ein Klick auf einen Namen ffnet das BlankerPrefs-Fenster, in dem die Einstellungen f r diesen Blanker gesetzt werden k nnen. Steht das Edit-Gadget jedoch auf "Auswahl/Selection", erscheinen vor den Namen jeweils " " oder " ". Ein " " bedeutet, da dieser Blanker ver- wendet wird, ein " " markiert einen ausgeschalteten Blanker. Durch Klick auf die Namen wechseln die Blanker zwischen den verschiedenen Betriebszu- nden. Es mu mindestens ein Blanker eingeschaltet bleiben. Nur aus eingeschalteten Blankern wird dann im Lotterie-Verfahren einer zum Blanken ausgew Ist die Liste schraffiert dargestellt (geht nur unter OS3.0) oder reagiert sie nicht, oder ist sie leer, dann stimmt der Pfad nicht. Bei Path korrigieren. Es kann sein, da etwas am Blankers-Verzeichnis ge ndert wurde und Mad- house noch den alten Verzeichnisinhalt anzeigt. In diesem Fall braucht man nur den Cursor in das Path-Gadget setzen (anklicken) und zu cken. Wenn zus tzlich abgespeichert wird, sind die Einstellungen auch beim n chsten Programmstart wieder vorhanden. Weitere Infos in @{"Der Workshop", link workshop}, Punkt 5. @endnode @node main_path "Referenz - Hauptfenster: Pfad/Path" Wenn das "Benutzen/Use"-gadget und einige andere unzug nglich sind, wurde ein falscher Pfad eingestellt. In diesem Gadget mu der Pfad eingetragen werden, in dem Madhouse seine Blanker sucht. Normalerweise endet der Pfad mit /blankers, sofern der Name dieses Verzeichnisses nicht ge ndert wurde. Madhouse erkennt den Pfad brigends nur als richtig, wenn sich noch die Datei "the_right_drawer" darin befindet. Der Pfad mu absolut sein, d.h. den Namen der Diskette enthalten. @endnode @node main_advOpt "Referenz - Hauptfenster: Weitere Optionen/Advanced Options" Madhouse hat mehr Optionen als in ein Hauptfenster passen... Deshalb gibt es noch die Weiteren Optionen/Advanced Options, was nichts mit Chipsets zu tun hat. Nach einem Klick auf den Button ffnet sich ein Fenster mit satten 9 Gadgets zum Einstellen bestimmter Dinge, die Madhouse zu etwas Besonderem machen. Die erkl re ich aber nicht hier, sondern in @{"Die Advanced Options", link adv_op}. @endnode @node main_time "Referenz - Hauptfenster: Zeit/Time" Nachdem die letzte Eingabe schon eine bestimmte Zeit her ist, wird der erste Blanker gestartet. Diese Zeit kann mit dem "Zeit/Time"-Slider einge- stellt werden. Die Zeit wird in Sekunden gemessen. @endnode @node main_changeBl "Referenz - Hauptfenster: Blanker wechseln/Exchange Blankers" Mit diesem Gadget wird bestimmt, ob Madhouse die Blanker mitten im Blanken auswechseln soll. So l t sich im BlankerPrefs-Fenster mit dem "Dauer/ Duration"-Slider f r jeden Blanker bestimmen, wie lange er laufen soll. Der Slider wird freigegeben, wenn "Blanker wechseln/Exchange Blanker" aktiviert Da das Wechseln des Blankers aber nur Sinn macht, wenn auch zwei oder mehr Blanker in der Liste aktiviert sind, ist dieses Gadget auch nur dann ver- gbar. @endnode @node main_save "Referenz - Hauptfenster: Speichern/Save" Schlie t das Fenster und sichert die Optionen. Diese Dinge werden dann nach "ENVARC:/ENV:Madhouse.prefs" gespeichert: - Die Optionen des Hauptfensters bzw. der System-Seite. - Die Optionen des Advanced-Options-Fensters bzw. der Advanced/Optionen- Seite. - Die aktuelle Position des Waiting-For-Disk-Fensters; siehe @{"Advanced-Options-Beschreibung", link adv_op}. - Die Duration-Einstellung f r jeden Blanker. - Die Namen und ein/aus-Einstellungen der Blanker. @endnode @node main_use "Referenz - Hauptfenster: Benutzen/Use" Dieses Gadget schlie t das Hauptfenster und l t Madhouse 'am Leben'. Die Einstellungen werden bernommen, aber nicht abgespeichert. @endnode @node main_remove "Referenz - Hauptfenster: Entfernen/Remove" Beendet Madhouse. @endnode @node main_info "Referenz - Hauptfenster: Info" Ein kleines Fenster ffnet sich und zeigt einige Informationen ber Mad- house und die Autoren. @endnode @node ref_littlewin "Referenz: Das AskForDisk-Fenster (bei Nach Disk fragen)" Das AskForDisk-Fenster (also das Fenster mit der kleinen Diskette) zeigt an, da der gepufferte Blanker bereits benutzt wurde und da Madhouse darauf lauert, die Blankers-Diskette in die Finger zu bekommen. Ein Klick auf das Schlie -Gadget dieses kleinen Fensters bewirkt nicht nur das Schlie en des Fensters, sondern stellt auch alle Schn ffel- versuche nach der Diskette ein. @endnode @node ref_editPrefs "Reference: The BlankerPrefs-window" @{B}I. Wie dieses Fenster ge ffnet wird:@{UB} Dieses Fenster l t sich ganz einfach ffnen: Einfach das Hauptfenster ffnen, dann das Edit-gadget auf "Prefs..." stellen und einen Blanker anklicken! MUI-User m ssen auf die Blankers-Seite wechseln und dann einen Blanker anklicken. @{B}II. Die Gadgets@{UB} Genialerweise ndern sich die Gadgets, je nachdem welcher Blanker ange- klickt wurde. Einige sind jedoch immer gleich: @{I}II.1 Das Okay-Gadget@{UI} Speichert die Einstellungen unter "blankers/blankername/prefs". @{B}Achtung:@{UB} Der Wert des Duration-Sliders wird hiermit nicht gespeichert, sondern nur mit dem Save-Button des Hauptfenster! @{I}II.2 Das Testen/Test-Gadget@{UI} Dieses Gadget starte den Blanker mit den aktuellen Einstellungen. @{I}II.3 Das Abbruch/Cancel-Gadget@{UI} t das BlankerPrefs-Fenster ohne die Einstellungen zu bernehmen. @{I}II.4 Der Dauer/Duration-Slider (MUI: auf der Blankers-Seite vorhanden)@{UI} Mit diesem Gadget wird eingestellt, wie lange Madhouse diesen Blanker zeigt. Da die Blanker aber nur mit aktiviertem "Blanker wechseln/Exchange Blankers" mittendrin abbrechen und wechseln, macht dieser Slider nur mit "Blanker wechseln/Change Blanker" Sinn. Andernfalls ist er nicht bedienbar (schraffiert). @endnode @node ref_muimainwin "Referenz: Das MUI-Hauptfenster" @{B}Die Gadgets um unteren Fensterrand:@{UB} @{" Speichern/Save ",link main_save} @{" Benutzen/Use ",link main_use} @{" Entfernen/Remove ",link main_remove} @{B}System-Seite@{UB} @{" Listengadget ",link ref_muilist} @{" Pfad/Path ",link main_path} @{" Zeit/Time ",link main_time} @{"Blanker wechseln/Exchange Blankers",link main_changeBL} @{B}Advanced/Optionen-Seite@{UB} Siehe @{" Advanced Options ", link adv_op} @{B}Blankers-Seite@{UB} @{" Listengadget ",link ref_muibllist} @{" Dauer/Duration ",link ref_muiduration} @{" Autor/Author ",link ref_muiauthor} @{" CPU-Belastung/CPU load ",link ref_muicpuload} @{" Version ",link ref_muiversion} @{" Das Sound-Men als PopUp ",link ref_muisound} @{B}Info-Seite@{UB} @{" Textgadget ",link ref_muiinfo} @endnode @node ref_muilist "Referenz - Hauptfenster/System: Listengadget" Die Liste links erm glich die An- und Abwahl der einzelnen Blanker. Nur die Blanker, die hier ausgew hlt werden, werden sp ter von der Zufallsfunktion herangezogen. Die Auswahl mit der Liste kann umst ndlich sein, wenn MUI unpraktisch konfiguriert wurde. Im MUI-Einstellungsfenster sollte auf der Listen-Seite das Gadget Auswahl auf "immer" stehen. Zus tzlich wird eine MUI-Multiselect-Liste bersicht- licher, wenn man auf der Bilder-Seite folgende Zuordnungen vornimmt: BG Listview -> Stift / System / Hintergrund oder Fremd / irgendein Muster BG Listview Cursor -> Muster / Scheinstift BG Listview Selected -> Stift / System / F llstift BG Listview Selected+Cursor -> Muster / Schatten/F ll-Raster Wird die Liste schraffiert dargestellt, dann ist die Pfad/Path-Einstellung falsch. @endnode @node ref_muibllist "Referenz - Hauptfenster/Blanker: Listengadget" Die Blanker-Liste auf der Blankers-Seite ist f r zwei Aufgaben zu ge- brauchen: zwischen den Funktionen wird mit der Art des Mausklicks ent- schieden. - Einfachklick: Die Informationen zum angeklickenten Blanker werden in den beiden Text- boxen angezeigt, die sich rechts von der Liste befinden. - Doppelklick: Das BlankerPrefs-Fenster wird ge ffnet. Finden sich in der gadget-Datei des angeklickten Blankers keine Informationen zum Aufbau eines MUI- Fensters, wird eben ein Normales aufgemacht. @endnode @node ref_muiduration "Referenz - Hauptfenster/Blanker: Dauer/Duration" Mit diesem Gadget wird eingestellt, wie lange Madhouse den aktiven Blanker zeigt. Da die Blanker aber nur mit aktiviertem "Blanker wechseln/Exchange Blanker" mittendrin abbrechen und wechseln, macht dieser Slider nur mit "Blanker wechseln/Exchange Blanker" Sinn. Andernfalls ist er nicht bedien- bar (schraffiert). @endnode @node ref_muiauthor "Referenz - Hauptfenster/Blanker: Autor/Author" In diesem Textfeld wird der Name des Autors angezeigt, der den gerade angew hlten Blanker programmiert hat. @endnode @node ref_muicpuload "Referenz - Hauptfenster/Blanker: CPU-Belastung/CPU load" Dort ist die St rke ersichtlich, mit der der Blanker das System belastet. Danach entscheidet Madhouse - falls das Gadget "CPU aktiv/CPU active" auf der Advanced/Optionen-Seite auf "nur einfache Blanker/only simple ones" steht und ein Programm arbeitet - welcher Blanker verwendet werden kann. Siehe auch @{"Advanced Options", link adv_op}. Die "Rechenintensivit t" des Blankers wird im Feld "CPU-Belastung/CPU load" angezeigt. "niedrig/low" bedeutet eine niedrige Belastung, "mittel bis hoch/medium to high" eine mittlere bis starke Belastung. @endnode @node ref_muiversion "Refernz - Hauptfenster/Blanker: Version" In diesem Textfeld wird die Versionsnummer des vorliegenden Blankers angezeigt. @endnode @node ref_muisound "Referenz - Hauptfenster/Blanker: Sound" Mit diesem Sound-Men kann man jedem Blanker einen Sound zuordnen, au erdem glicht es dieses PopUp, sich die Musik-Module anzuh @{FG Highlight}Dazu wird entweder die medplayer.library oder der DeliTracker benutzt, je nachdem, was auf der Advanced/Optionen-Seite eingestellt ist. Falls der DeliTracker benutzt wird, mu der DeliTracker laufen; sonst mu medplayer.library verf gbar sein und dann darf das Modul auch nur ein MED-Modul sein.@{FG Filltext} chst mu man in der Liste links einen Blanker ausw hlen (1x klicken), der "vertont" werden soll. Das Stringgadget neben "Sound" enth lt nun das r diesen Blanker eingestellte Modul - also im Moment noch nichts. Das PopUp-Gadget (MUI wird heute mal voll ausgereizt *(:-) ) auf der rechten Seite mu auch noch bet tigt werden, schon ffnet sich ein liebevoll designtes PopUp-Fenster. Dieses PopUp besteht aus mehreren Elementen: @{FG Highlight}Hinzuf gen... / Add...@{FG Filltext} Dieser Button mu chst bet tigt werden, um ein Sound-Modul in die Li- ste zu bekommen @{FG Highlight}L schen / Del@{FG Filltext} Hiermit wird ein Modul komplett aus Madhouse gestrichen. Jeder Blanker, bei dem dieses Modul eingestellt war, hat nun keine Sound-Einstellung mehr, und das Modul wird aus der Liste entfernt. @{FG Highlight}Tapedeck-Play-Pfeil@{FG Filltext} Nun, es soll ja Leute geben, die sich die Bedienungsanleitungen von Radiorekordern, Tapedecks, CD-Playern und Videorekordern durchlesen. Die haben jetzt keine Chance, weil ich nicht erkl ren werde, was dieser Button macht. Notfalls schaut halt in die Anleitung vom Auto- Radio, Euch ist ja eh' nicht zu helfen. @{FG Highlight}Tapedeck-Stop-Quadrat@{FG Filltext} Mit diesem Knopf wird das Musik-Modul wieder gestoppt. % @{FG Highlight}Liste@{FG Filltext} Ach ja, die Liste: die hat eigentlich gar keine Bedeutung. Die ist nur da, weil die Leute sowas erwarten, wenn sie ein PopUp ffnen. Anstatt des Sound-Men tte es n mlich auch ein simpler File-Requester getan, aber wenn man nun mal gerne programmiert... Zugegeben, man k nnte das Sound-Modul auch direkt in das Stringgadget ein- tragen. (Der Hypermegasupergeheimtip.) brigens wird die Liste selbst nie abgespeichert. Falls also ein Modul hin- zugef gt, aber nicht benutzt wird, befindet es sich beim n chsten Start des MadhouseConfigEd nicht mehr in der Liste. Die Liste wird vielmehr am Programmstart des ConfigEd anhand der eingestellten Module erstellt. Einen interessanten Tip von Aicke m chte ich auch nicht verschweigen: wenn Ihr nicht wollt, da der DeliTracker nach jedem Blanken wieder eines sei- ner eigenen Module nachl dt (wenn er also ohne Madhouse ruhig sein soll), dann schaltet doch einfach die Option "Play at Start" ab. @{FG Highlight}Halt, nach dieser sehr sinnvollen Beschreibung des Sound-PopUps noch was Wichtiges: Eigentlich kann man die Sound-Funktion nur mit einer Festplatte benutzen (die sowieso jeder Anwender haben sollte), weil Madhouse immer davon ausgeht, da das Modul ohne Diskettenwechsel (und damit ohne "Please insert Disk..."-Requester) ladbar ist. Uneigentlich geht es aber auch ohne, dazu mu man das betreffende Sound- Modul jedes Blankers in sein Unterverzeichnis kopieren. In das Sound-Gadget (nicht ins PopUp, das wird nicht gehen) mu man dann RAM:Madhouse_Storage/mod.Musikmodul eintragen, vorausgesetzt "Puffern/Buffering" ist eingeschaltet und das Modul hei t "mod.Musikmodul". Diesen Trick sollte man aber nur mit dem DeliTracker anwenden, weil Madhouse die medplayer.library erst kurz vor dem Abspielen ffnet, was auch ein "Please insert Disk..." hervorrufen kann. Siehe auch @{"Puffern/Buffering-Option", link buffering}.@{FG Filltext} @endnode @node ref_muiinfo "Referenz - Hauptfenster: Info" In diesem Gadget werden einige Informationen ber uns angezeigt. Au erdem findet Ihr hier das Madhouse-Logo (was Ihr bestimmt gesucht habt!) @endnode @node programmers "F r Programmierer: eigene Module schreiben!" Da Madhouse ein offenes System ist, kann man leicht eigene Module hinzu- gen. Eure erste Frage ist sicherlich @{" Kann ich meine Programmiersprache benutzen? ", link p_language} Danach k nnt Ihr einen Blanker schreiben und ihn Compilieren. @{" Wie soll ich den Blanker schreiben? ", link p_code} Jetzt f gt Ihr Euren Blanker in den Madhouse-Verzeichnisbaum ein. @{" Mein eigenes Verzeichnis! ", link p_dir} Dies ist alles was Ihr braucht, um einen einfachen Blanker zu schreiben. Aber ein richtiger Blanker hat schlie lich auch Einstellungen, und die ndert der User ja in Eurem zuk nftigen BlankerPrefs-Fenster. Madhouse erstellt es nach Euren W nschen - oder besser gesagt, nach Eurer Datei. Sie hei t "gadget" und mu sich im Verzeichnis des neuen Blankers befinden. Und die wird jetzt erstellt. @{" Die gadget-Datei. ", link p_gadget} Und fertig! Wer hiermit Probleme hat, der sollte uns unbedingt schreiben. Schlie lich hat jeder Programmierer einmal angefangen und ich hatte keine Versuchsperson, die nur anhand dieser Anleitung einen Blanker schreiben sollte. Gerade weil f r einen modularen Screenblanker die verf gbaren Mo- dule das Wichtigste sind, werden wir hier jede uns m gliche Unterst tzung liefern. Nat rlich kennen wir nicht jede Programmiersprache, aber das ist oft auch nicht n @{FG Highlight}Noch ein paar Worte an Leute, die tats chlich einen Blanker schreiben und ffentlichen wollen: 1. Wir haben bestimmte Dinge bewu t nicht gemacht (?). So haben wir bewu keinen Lines-Blanker geschrieben, weil der nicht gut aussieht und nicht originell genug ist. Nat rlich k nnt Ihr ver ffentlich, was Ihr wollt, aber es w re schon, wenn das Niveau von Madhouse erhalten bliebe. Die Idee sollte also irgendwie ausgefallen sein. 2. Vielleicht denkt Ihr, es ist praktisch, Madhouse zusammen mit Eurem Blanker zu ver ffentlichen. Tut das bitte nicht, denn Madhouse darf nur @{B}unver ndert@{UB} weitergegeben werden. Wenn Ihr Euren Blanker zwischen unseren sehen wollt, k nnt ihr ihn uns schicken. Dann ist er in der n chsten Version dabei. In diesem Fall mu er sich dann aber unserer Qualtit tskontrolle unterziehen (das h rt sich jetzt arrogant an, aber irgendwie mu man sich ja absichern wenn doch einer mit Lines ankommt). Bitte seid nicht b se, wenn der Blanker mit drei Seiten Verbesserungsvorschl gen zur ckkommt.@{FG Filltext} @endnode @node p_language "Kann ich meine Programmiersprache benutzen?" Ja. Wenn Ihr jetzt denkt, da Ihr mit BASIC-m igen Dialekten keine Chance habt, dann liegt Ihr falsch. Immerhin wurden viele Blanker in AMOS ge- schrieben, und das will schon was hei en (ich will hier nicht das Ger verbreiten, AMOS w re nur zu sich selbst kompatibel. Nachher folgt dann in der n chsten Version dieser Anleitung eine Gegendarstellung, die ich dann noch nicht einmal unterschlagen darf... oder so). OK, wer also meint AMOS benutzen zu m ssen, der soll das eben tun. Um es auf dem Punkt zu bringen, mir fallen nur zwei "Sprachen" ein, mit denen Ihr kein Gl ck haben werdet. ARexx und AmigaDOS. "Waaaas, letzteres ist eine Programmiersprache?" Streng genommen schon. Noch nie was von Batch-Dateien geh rt? Gut so. ARexx geht auch nicht, weil man da keine Screens ffnen kann. "Und das t Ihr mir jetzt einfach glauben", w rden die Physik-Lehrer sagen. ARexx w rde es theoretisch schaffen, wenn jemand vorher eine ARexx- Extension-Lib mit neuen Befehlen f r Screens und Zeichnen und so in Assembler oder C schreiben w rde. Und da h rt dann der Sinn irgendwie auf, oder? Tats chlich existiert eine solche Library, die m t Ihr jetzt aber schon selbst suchen, und au erdem br uchtet Ihr dann noch den 250,-DM teuren ARexx-Compiler, und daf r bekommt man ja schon eine richtige Pro- grammiersprache. Tja, l ngst habt Ihr es gemerkt. Ich bem he mich immer, einleuchtend, klar verst ndlich und f r jeden begreiflich zu schreiben. Kurz fassen kann ich mich aber nicht. Um also wieder auf den Punkt zu kommen: hiermit definiere ich eine Madhouse-Blanker-m gliche Sprache als alle Amiga-Sprachen abz glich der Sprachen f r die es keinen Compiler gibt oder die keine M glichkeit bereitstellen, Screens oder Fenster zu ffnen. r AMOS und GFA-BASIC (und Amiga-BASIC...) gibt es den Compiler extra zu kaufen. F r ARexx auch, aber diesen Punkt h tten wir ja nun abgehakt. BlitzBasic, C, Pascal, Assembler, Oberon, Modula, Amiga-E, und alles was mir sonst einfallen k nnte sind sog. Compiler-Sprachen und werden deshalb GARANTIERT mit Compilern ausgeliefert, da der Compiler sozusagen die Sprache ist, wie sich ein Einsteiger ausdr cken w Alles klar? AmigaDOS (und ARexx?) sind aus dem Rennen, dem Rest w nsche ich viel Spa @endnode @node p_code "Wie ich meinen Blanker schreibe." Wie Ihr Euren Blanker schreibt m t nat rlich Ihr entscheiden, aber ich kann Euch sagen, wie er an die Daten von Madhouse herankommt und wie er Madhouse Infos bermitteln mu Um die Kommunikation zwischen Blanker und Madhouse "programmiererfreund- lich" zu gestalten (schlie lich wollen wir hier niemanden zum Umsteigen auf C zwingen...), haben wir uns entschlossen, alles mit Dateien abzu- wickeln. Das hei t, da Madhouse eine bestimmte Datei, die immer denselben Namen und Pfad hat, mit Informationen f r den Blanker f llt. Dann ruft es den Blanker auf und macht erst weiter, wenn sich der Blanker beendet hat. Der Blanker liest die Datei und zieht daraus seine Schl sse - die Datei namens "RAM:Madhouse_Storage/prefs" enth lt die Einstellungen des Blankers sowie die Duration-Zeit in Minuten (entspricht dem Duration-Slider im BlankPrefs-Fenster) und einen neuen Pfad, der ihm sagt, wo sich sein Hauptverzeichnis befindet. Diesen Pfad braucht man in den seltensten llen, n mlich genau dann, wenn man eine Datei aus dem Verzeichnis nach- dt. Alle numerischen Angaben sind im Kartext geschrieben, z.B. "23" statt ". Die Frage "Wieviele Einstellungen hat denn mein Blanker?" solltet Ihr selbst beantworten k nnen... Da ein Programmlisting solche Sachverhalte am besten verdeutlichen kann, gibt es drei Beispielprogramme. Das Erste ist in dieser Datei enthalten und folgt gleich. Es ist sozusagen allgemein gehalten. Au erdem tut der Blanker hier nicht etwas bestimmtes und auch auf die Parameter wollte ich mich nicht festlegen. Die beiden anderen Programme befinden sich im developers-Verzeichnis und sind in C und AMOS geschrieben. Sie enthalten richtige, handfeste Beispiele. Im Unterverzeich- nis mit dem AMOS-Beispielblanker befindet sich noch eine Configurations- Datei f r die AMOSPro-Compilershell. Diese k nnt Ihr einfach laden, schon sind die Einstellungen korrekt. brigens sollte man auf die abar- tigen "Amos lock/unlock"-Kommandos achtgeben. Datei "RAM:Madhouse_Storage/prefs" zum Lesen ffnen. Ersten eigenen Parameter lesen. Zweiten eigenen Parameter lesen. n-ten eigenen Parameter lesen. Blank-Dauer in Minuten lesen. Pfad auf die eigenen Dateien lesen. Pfad ist z.B. "RAM:Madhouse_Storage" oder "Work:Madhouse/Blankers/MeinBl". // Wenn die Zeit in Ticks ermittelt wird (DateStamp, der Timer) Blankdauer = Blankdauer * 300 // Wenn die Zeit in Sekunden ermittelt wird (mit Include ) Blankdauer = Blankdauer * 60 Screen ffnen. Wenn Fehler, dann Datei "RAM:Madhouse_Storage/errors" zum ANH NGEN (!) ffnen. Den Fehler in eine Zeichenkette kopieren, an diese Zeichenkette das ASCII-Zeichen nummer 13 (0x0D) anh ngen, Fehler in Form EINER kurzen Zeichenkette schreiben. Datei schlie Programm beenden. Aktuelle Systemzeit (Ticks) in eine Variable legen. r immer Blanken Blanken Blanken (was der Blanker halt so in einer Hauptschleife macht...) Wenn Maustaste gedr ckt oder Tasteneingabe auf der Tastatur dann Datei "RAM:Madhouse_Storage/Blankstop" zum Schreiben ffnen. Datei schlie Screen schlie Programm beenden. ) Wenn Blanker-Dauer ungleich 0 dann Zeit messen. Wenn (aktuelle Zeit - Startzeit) > Blank-Dauer dann Screen schlie Programm beenden. ) Ein paar Erl uterungen sind sicher n tig. So bedeutet die ) ein ENDIF- iges Sprachkonstrukt. Die Umrechnung der Blankdauer (*300 oder *60) mu erfolgen, da Madhouse die Zeit in Minuten bergibt. Da man aber die Zeit in Sekunden oder Ticks stoppt und die Startzeit in die Variable legt, mu man die Madhouse- Blankdauer mit 60 (Stoppeinheit Sekunden) oder mit 300 (Stoppeinheit Ticks) multiplizieren. Dies wird auch in den beiden Beispielprogrammen veran- schaulicht: das C-Demo benutzt die Funktion time() und die Struktur time_t aus und arbeitet in Sekunden. Das AMOS-Demo liest den Timer aus, welcher die Zeit nach dem Einschalten in Ticks beinhaltet. In die Errors-Datei darf deshalb nur eine Zeile ANGEHANGEN werden, weil Madhouse die Datei erst auswertet, nachdem evtl. mehrere Blanker liefen. So wird ein berschreiben der Datei verhindert. erdem ist noch wichtig, da jeder Blanker nur EINMAL EINE ZEILE in die "errors"-Datei schreiben darf, die dann von Madhouse umbrochen wird. Und noch viel wichtiger ist, da diese eine Zeile maximal 500 Zeichen lang sein darf. Die "prefs"-Datei sieht im brigen z.B. so aus: $Ein toller Text! RAM:Madhouse_Storage Dann hatte der Blanker selbst vier Einstellungen, die man im Prefs-Fenster hlen kann. Sie werden hier in der Reihenfolge bergeben, in der auch die Gadgets in der "gadget"-Datei definiert sind, doch dazu sp Hinter die Blanker-Einstellungen h ngt Madhouse die Zeit in Minuten, die der Blanker maximal blanken kann. Ist sie null, l uft er tats chlich bis der Benutzer ihn abbricht. Als "Abbrechen" gilt brigens nur eine Maus- oder Keyboard-Taste. Strings werden Madhouse-Technisch mit einem $ ange- hrt. Die Blanker-Einstellungen k nnen alles m gliche sein, z.B. - der Wert eines Cycle-Gadgets - der Wert eines Sliders - der Zustand eines H kchen-Gadgets (0 oder nicht 0 [0 hei t "aus".]) - u.v.m. Wie der Blanker das auswertet, bleibt ihm selbst berlassen. Ein sehr einfacher Blanker hat selbst gar keine Einstellungen und kein Prefs-Fenster. Er liest dann z.B. nur Work:Madhouse/Blankers/MeinBlanker und reagiert darauf. Die "gadget"-Datei kann sich solch ein Blanker schenken, daf der Programmierer so eines Blankers aber eine prefs- Datei selbst erzeugen, mit 0 Bytes L nge. (So eine "leere" Datei befindet sich auch im developer-Verzeichnis, unter dem Namen "emptyprefs".) Das Executable, also die Datei, die hinten beim Compiler rauskommt, darf sich brigens auf keinen Fall vom CLI abkoppeln. Dies mu auch im AMOSPro- Compiler in der Compiler-Shell eingestellt werden (Option: CLI-Program to run in the Background... No - oder so hnlich). brigens ist es f AMOS-Programmierer schon recht wichtig, die mitgelieferten Compiler- Settings zu benutzen. Aicke und ich hatten damals eine Menge rger, als wir erstmals einen AMOS-Blanker in das System integrierten. Den solltet Ihr Euch mit der mitgelieferten Config-Datei ersparen. @endnode @node p_dir "Mein eigenes Verzeichnis!" Madhouse f r jeden Blanker ein eigenes Verzeichnis erwartet, sollte nun langsam klar sein. Deshalb solltet Ihr jetzt ein Verzeichnis mit dem Namen des Blankers im Madhouse-Blanker-Verzeichnis-Pfad (Ihr wi t, was ich meine...) anlegen. Ein Verzeichnis hat im brigen nicht nur die Aufgabe, alles beisammen zu halten, User ohne Festplatte k nnen - falls Euer Blanker die Angabe eines Dateinamens erlaubt - diese Datei in das Blankerverzeichnis ko- pieren. Da bei eingeschaltetem Buffering immer das gesamte Verzeichnis im RAM gehalten wird, wird dann diese Datei auch erreichbar sein. Der User gibt dann nur den puren Dateinamen an. Der Blanker versucht erst, den Pfad, den Madhouse in die letzte Zeile der Prefs-Datei schreibt + "/" + den Dateinamen zu ffnen, wenn das fehlschlug, dann nur den Datei- namen allein. Bei eingeschaltetem Buffering geht die erste Variante: aus dem Dateinamen "File" wird dann "RAM:Madhouse_Storage/File". Bei ausgeschaltetem Buffering gt diese Variante fehl, denn der User mit Festplatte mu ja seine Datei nicht in das Unterverzeichnis des Blankers kopieren. Er gibt z.B. an: "Work:Pictures/File" und es entsteht "Ram:Madhouse_Storage/Work:Pictures/File", was sich nat rlich nicht ffnen t. Daf r funktioniert dann aber Variante 2 (nur der Dateiname): "Work:Pictures/File" m te sich jetzt ffnen lassen. Das Verzeichnis kann nat rlich auch zus tzliche Dateien beinhalten, die der Blanker dann beim Start immer nachl dt. Wichtig ist aber, da diese Dateien nicht "errors" oder "stopblank" hei rfen. Ebenfalls rfen keine weiteren Unterverzeichnisse angelegt werden. Also dann, macht ein Verzeichnis und legt das Kompilat Eures Blanker hinein. Der Blanker mu den Namen "blanker" tragen (ach so). erdem solltet Ihr noch eine leere Prefs-Datei erzeugen, wenn ihr den Blanker zuerst ohne gadget-File und ohne BlankerPrefs-Fenster von Madhouse aus starten wollt. Diese Datei mu dann "prefs" hei en (ach ja) und sich in Eurem Blankers-Verzeichnis befinden. Da es nicht so leicht ist, eine Datei wirklich leer zu machen, k nnt Ihr die leere prefs-Datei aus dem developers-Verzeichnis benutzen. Diese leere Datei k nnt Ihr Euch sparen, wenn Ihr jetzt die folgenden beiden Abs tze nicht mitmacht und gleich an die gadgets-Datei geht. Danach ruft Ihr einfach das BlankerPrefs-Fenster Eures Blankers auf, bewegt alle Slider und klickt auf Save. Schon habt ihr eine fertige Prefs-Datei. Jetzt mu Madhouse gestartet werden. Klickt einmal ins "Path"-String- gadget und dr ckt , damit Madhouse das Verzeichnis neu einliest. Das BlankerPrefs-Fenster kann nat rlich noch nicht ge ffnet werden, da die Definitionsdatei daf r nach fehlt. Wenn der Blanker schon so pro- grammiert wurde, da er eigene Einstellungen liest, m t Ihr halt selbst eine prefs-Datei schreiben, die NUR DIE EINSTELLUNGEN DES BLANKERS ent- lt. Wie so etwas auszusehen hat, wi t Ihr ja. Aber soetwas w rde ich selbst nicht gleich ausprobieren, besser erst den Blanker anpassen, so er keine eigenen Einstellungen l Bei "Selection" k nnt Ihr noch Euren Blanker allein ausw hlen, auf "Use" klicken und - warten. @endnode @node p_gadget "Die gadget-Datei" Da ja mittlerweile auch den Lesern der Commodore-Dokumentation klar ist, was Gadget hei t (Ihr wi t schon, die Dinger auf die Ihr dauernd klickt..), rfte die Bedeutung der "gadget"-Datei, die eigentlich jeder Blanker in seinem Verzeichnis hat, klar sein. Sie enth lt u.a. die Beschreibung, wie das BlankerPrefs-Fenster des jeweiligen Blankers aussieht. Und damit der Anfang wieder einfach wird, schauen wir uns zun chst eine solche Datei an, die ich zwecks Dateif llung mal hier eingef gt habe. (Anm.: Diese Datei ist nicht lokalisiert, d.h. ist nur einsprachig. Zur Erzeugung mehrsprachiger BlankerPrefs-Fenster komme ich sp ter.) Madhouse v1.0, BlankerPrefs-Window CHUNK:DIMENSIONS Gadgets 3 Texts 5 Arrays 1 CHUNK:WINDOW 338,62 CHUNK:DURATION_POS 112,53,150,12 CHUNK:GADGETS Cycle,112,4,150,12,Mode,TextLeft 1,Done 3,Bouncing Point,Wusel,Random Slider,112,19,150,12,Wusel lenght,TextLeft 5,SlMin,1,SlMax,20,Done Checkmark,112,34,26,12,Sound,TextLeft 1,Done (.... Hier steht noch die MUI-Fensterbeschreibung, die ich weiter unten re. Sie ist nicht zwingend notwendig.) CHUNK:BEVELBOXES 0,0,330,49 0,49,330,20 CHUNK:BLANKERINFO Aicke Schulz Ha! Obwohl Ihr bisher nicht die leiseste Ahnung vom Aufbau der Datei habt, kann jetzt jeder sofort sehen, von welchem Blanker die Datei stammt. Es tauchen n mlich bestimmte Schriftz ge auf, die der erfahrene (ahem..) Madhouse-User schon gesehen hat. Na klar, von CrazyPixel stammt diese Datei. Und offensichtlich ist sie auf eine bestimmte Art strukturiert. So ist des fteren das Wort CHUNK darin zu finden. Auf f nf Dinge ist zu achten: - Der Text "Madhouse v1.0, BlankerPrefs-Window" MUSS sich in der ersten Zeile befinden. - Die Chunks k nnen gemischt werden. - Der erste Chunk mu der "CHUNK:DIMENSIONS" sein. Hier ist auch leider der etwas invariable Programmierstiel erkennbar, den ich f r die Daten dieses Fenster angewandt habe... (mit MUI ist das alles schon etwas genialer programmiert worden, aber egal.) - Es d rfen keine Leerzeilen innerhalb des Chunks liegen. Auf Recht-, Gro - und Kleinschreibung wird geachtet. Ausnahmen nerven die Regel: weil sonst die bersicht echt futsch gegangen w re, sind im CHUNK: - GADGETS doch Leerzeilen m glich, aber auch dort nicht berall...! - Es d rfen Leerzeilen zwischen den Chunks stehen, ein Chunk (CHUNK:GADGETS) erlaubt auch Leerzeilen zwischen den einzelnen Gadget- Definitionen. (Also zwei Regeln und eine Ausnahme.==) Als kleinen berblick will ich noch die Funktionen der einzelnen Chunks er- ren, bevor ich weiter unten genau auf die Details eingehe. Der CHUNK:DIMENSIONS sagt Madhouse, wieviele Gadgets das BlankerPrefs-Fen- ster haben wird, damit es rechtzeitig den Speicher f r die Daten besorgen kann. Die beiden anderen Angaben haben ebenfalls mit der Speicherverwaltung zu tun. Der CHUNK:WINDOW bestimmt die Ausma e des BlankerPrefs-Fensters (Breite und H Der CHUNK:DURATION_POS erlaubt die Positionierung des Duration-Sliders, der von Madhouse selbst erzeugt wird und der sich in allen BlankerPrefs-Fen- stern befindet. Im CHUNK:GADGETS wird jedes Gadget des BlankerPrefs-Fensters gesondert de- finiert. Die Buttons Okay, Test und Cancel sowie der Duration-Slider wer- den hier nicht erstellt. Anhand des CHUNK:GADGETS bastelt Madhouse die Daten zusammen, die vom Betriebssystem zum ffnen des Fensters ben werden. Der CHUNK:LOCALE mu nicht vorhanden sein, erlaubt es jedoch, mehrsprachige BlankerPrefs-Fenster zu erzeugen. Nur sinnvoll und m glich, wenn der CHUNK: GADGETS und evtl. der CHUNK:MUI-WINDOWLAYOUT entsprechend angepa t werden. Diese Anpassung wird ebenfalls hier erkl Der CHUNK:BEVELBOXES ist (wie auch der CHUNK:TEXTS) optional, d.h. er mu sich nicht in der gadget-Datei befinden. Der CHUNK:BEVELBOXES erm glicht, wenn vorhanden, die Erzeugung von plastischen Rahmen im BlankerPrefs- Fenster. Damit lassen sich verschiedene Gadgets prima gruppieren; in den Madhouse-Blankern wird dieser Chunk immer eingesetzt, um den Duration- Slider von den Blanker-Gadgets zu trennen. Mit dem CHUNK:TEXTS lassen sich beliebige Texte ins BlankerPrefs-Fenster einf Der CHUNK:BLANKERINFO mu dagegen wieder in jeder gadget-Datei enthal- ten sein. Er wird haupts chlich nur eingelesen, wenn Madhouse nach einer Eingabe im Path-Gadget des Hauptfensters das gesamte Blankers-Verzeichnis durchw hlt und die dort vorhandenen Blanker in der Liste eintr gt. Aus dem CHUNK:BLANKERINFO kann Madhouse ersehen, ob der Blanker rechenin- tensiv ist (siehe @{"Advanced Options",link adv_op}, Punkt 4 ), und mit wieviel Stack er gestartet werden mu Noch ein kleiner Tip: Wer nicht wei , was Radio-Gadgets u.s.w. sind, der kann sich auch den recht informativen Artikel in der Amiga-Plus 11/93, Seite 95f durchlesen. Hier werden auch die Einsatzgebiete der Gadgets utert. Wessen Fenster auch noch total (Commodore-) Standard aussehen sollen, der kann sich noch (aber das ist f r diesen Zweck echt bertrieben) den "AMIGA User Interface Style Guide", Addison-Wesley, 206 Seiten, ca. 60 DM 'reinziehen. Dieses Buch ist aber eigentlich nur f die Programmierer gedacht, die ein Programm mit Fenstern schreiben. Madhouse ist auch "Style-Guide"-konform, obwohl ich nie ein Blick in den Interface Style Guide warf. Mit der Zeit kapiert man einfach, da man die Gadgets nicht wild im Fenster herumstreuen sollte... Und jetzt folgt die Erkl rung der einzelnen Chunks. Mit "*" markierte Chunks m ssen nicht auftauchen, k nnen aber. (Optional.) @{" CHUNK:DIMENSIONS ", link p_dimensions } @{" CHUNK:WINDOW ", link p_window } @{" CHUNK:DURATION_POS ", link p_duration } @{" CHUNK:GADGETS ", link p_gadgets } @{" CHUNK:BLANKERINFO ", link p_blankerinfo } @{" * CHUNK:BEVELBOXES ", link p_bevelboxes } @{" * CHUNK:TEXTS ", link p_texts } @{" * CHUNK:LOCALE ", link p_locale } Bis jetzt habe ich Euch ganz diskret verschwiegen, wo denn nun die Blanker- Prefs-Oberf chen des @{B}MUI-@{UB}Programmteils herkommen. Auf meine Kosten kann mlich auch jeder Blanker, der in AMOS oder sonstwas geschrieben wurde, eine MUI-Oberf che haben. Die wird - wie konnte es anders sein - auch einen Chunk erzeugt. Man sollte den Text, der da oben steht, bereits verstanden haben um hier weiterzumachen. Ich baue jetzt n mlich ein bischen auf dieses Wissen auf. erdem sollten sich auch in jeder fremden gadget-Datei die Informationen zum Aufbau eines normalen Fensters (ohne MUI) finden, sonst kann Euer Blanker nur von Usern der MUI-Version genutzt werden. Umgekehrt k aber die MUI-Angaben fehlen. Doch MUI-Oberfl chen werden nicht einfach so pixelweise in den Raum ge- stellt, sondern bauen sich aus Beziehungen einfacher Gestaltungsm glich- keiten auf. Deshalb mu ich jetzt auch etwas weiter ausholen, denn die Beschreibung von MUI bleibt mir wohl nicht erspart. Vorher jedoch noch @{" Der MUI-Madhouse-Schnelleinstieg f r erfahrene MUI-Programmierer. ",link pm_exp} Alle anderen Leute mit MUI-Ambitionen lesen besser @{" MUI von Null auf Hundert f r MUI-Greenhorns. ",link pm_start} @{" Die MUI-Gruppentypen ",link pm_groups} @{" Die MUI-Gadgets ",link pm_gadgets} @{" Der CHUNK:MUI-PREFSORDER ",link pm_mpo} @endnode @node p_dimensions "CHUNK:DIMENSIONS" Dieser Chunk mu der erste Chunk sein. Er beinhaltet drei Zahlen: CHUNK:DIMENSIONS Gadgets x Texts y Arrays z x = Die Anzahl der Gadgets in Eurem Fenster. Hier werden nur selbst- definierte gez hlt, die Duration- und Test-Ok-Cancel-Buttons nicht. y = Die Anzahl der Texte. Sie ist Anzahl der Gadgets (f r den Namen) + die Anzahl der gesamten Auswahlm glichkeiten von Cycle- und Radio- gadgets. Die "richtigen" Texte des Text-Chunks werden nicht mitgez Also einfach die Menge der eigenen Gadgets und die Anzahl der Cycle- Eintr ge addieren, und man hat y. y = Die Menge der Cycle- und Radio-Gadgets. @endnode @node p_window "CHUNK:WINDOW" CHUNK:WINDOW x = Die H he des BlankerPrefs-Fensters in Pixeln. y = Die Breite des BlankerPrefs-Fensters in Pixeln. @endnode @node p_duration "CHUNK:DURATION_POS" CHUNK:DURATION_POS x,y,w,h Wie schon mehrmals angesprochen, geh rt der Duration-Schieber nicht zu den selbstdefinierbaren Gadgets. Madhouse erledigt hier die Arbeit. Da aber ein frei in der Gegend positionierter Slider nicht gut aussieht, gibt es trotzdem die M glichkeit, den Platz und die Gr e des Duration- Sliders zu bestimmen: x = Linke Ecke des Duration-Sliders. y = Obere Ecke des Duration-Sliders. w = Breite des Sliders. h = H he des Sliders. @endnode @node p_gadgets "CHUNK:GADGETS" Dieser Chunk enth lt 1 bis n-mal eine solche Angabe: Typ,x,y,w,h,Name,Flags Anzahl der Tags,Tag1,Data1,Tag2,Data2... [Anzahl der Array-Elemente,Element1,Element2,...] Vor jeder dieser Zeilenbl cke d rfen beliebig viele Leerzeilen (zur sichtlichkeit) stehen, jedoch nicht IN einem solchen Block (vgl. auch an- dere Gadget-Dateien). Das sieht jetzt sehr schwierig aus, aber man kann ja schlie lich bei den anderen Blankern abgucken... Au erdem werde ich noch Beispiele bringen. Die erste Zeile ist immer hnlich: Typ = Typ des Gadgets. Hier wird zwischen Stringgadgets (f r Zeichen- ketten), Sliders (die Schieberegler), Cycles (die 'Bl ttersym- bole'), Integergadgets (f r Ganzzahlen), Checkmarks (die H kchen- gadgets) und MX's (auch Radiobuttons genannt, hat nichts mit Rundfunk zu tun) unterschieden. Je nachdem, was f r ein Gadget man erstellen m chte, schreibt man hier String f r Stringgadgets, Checkmark f r Checkmark-gadgets, Slider f r Sliders Cycle f r Cycles Number f r Integer-gadgets oder Radio f r Radio- bzw. MX-gadgets. Die anderen Typen sind in Madhouse nicht m glich oder nicht re- levant. x,y,w,h = Die Positionen und Dimensionen des Gadgets. x,y = linke, obere Ecke, w = Breite, h = H Name = Text, der z.B. neben dem Gadget stehen soll. Flags = Hiermit wird definiert, wo der Text "Name" stehen soll: TextLeft der Text steht links neben dem Gadget, TextRight der Text steht rechts neben dem Gadget, TextTop der Text steht ber dem Gadget oder TextBottom der Text steht unter dem Gadget. Die zweite Zeile ist die Tag-Zeile. Denn manche Gadgets ben tigen noch weitere Informationen, und die werden mit Tags bergeben. Ein Slider z.B. wissen was sein Wertebereich ist. Die Tag-Zeile beginnt immer mit der Anzahl der Tags, z.B. "1". Viele Gadgets ben tigen so etwas aber nicht, deshalb schreibt man da 1,Done Jede Tag-Zeile mu mit einem "Done" aufh Bei einem @{B}Slider@{UB} hei 5,SlMin,minimum-Wert,SlMax,maximum-Wert,Done r "minimum-Wert" und "maximum-Wert" mu rlich etwas nach eigenen Vor- stellungen eingesetzt werden. Auch ein @{B}Stringgadget@{UB} kann Tags besitzen: 3,StMaxChars,maximale Anzahl Zeichen,Done Hier wird f r "maximale Anzahl Zeichen" ein Wert eingesetzt, der angibt, wieviel Zeichen das Stringgadget maximal aufnehmen darf. Wird mehr als 500 angegeben, oder lautet die Zeile nur 1,Done dann wird der Default-Wert von 500 Zeichen benutzt. Das waren schon alle Gadgets, die Tags ben tigen. Die Schl sselw rter ("String", "Checkmark", "TextRight", "SlMin", "Done", u.s.w.) k nnen in Egalschreibung geschrieben werden (also Pascal-gro oder C-klein oder ARexx-gemischt oder irgendwie). Die dritte Zeile ist die Array-Zeile. Cycle-Buttons und Radio-Gadgets noch mitgeteilt werden, was als m gliche Auswahl zur Verf steht. Achtung: sind die Werte im CHUNK:DIMENSIONS richtig gesetzt? (Man mu die Radio- und Cycle-Gadgets durchz hlen und das Ergebnis unter "Arrays" im CHUNK:DIMENSIONS eintragen. Dies steht aber dort erkl Als Beispiel dient jetzt ein Cycle, welches zwischen vier Farbpaletten umschalten l Cycle,140,20,200,12,Farbauswahl,TextLeft 1,Done 4,Farbset 1,Farbset 2,Farbset 3,Farbset 4 Die erste Ziffer ist wieder die Anzahl der Auswahlm glichkeiten. @endnode @node p_duration "CHUNK:DURATION_POS" @node p_locale "CHUNK:LOCALE" CHUNK:LOCALE sprache1,sprache2,... Bei der Lokalisierung von Madhouse sto ich auf das Problem der Blanker- Prefs-Fenster, die ja nicht auch noch alle ihren eigenen catalog haben sollten. Deshalb m ssen - falls dieser CHUNK in der Datei vorkommt - die Chunks GADGETS und MUI-WINDOWLAYOUT in den Angaben f r Gadgettexte jeweils alle verschiedenen Sprachen beinhalten. Um das nicht zu kompliziert zu ren, zeige ich Euch zwei Beispiele: CHUNK:GADGETS CYCLE,112,4,170,12,"Mode,Modus",TEXTLEFT 1,DONE 3,"Bouncing Point|Wusel|Random,Springender Punkt|Wusel|Zufall" SLIDER,112,19,170,12,"Wusel lenght,Wusell nge",TEXTLEFT 5,SLMIN,1,SLMAX,20,DONE CHECKMARK,112,34,26,12,"Sound,Toneffekt",TEXTLEFT 1,DONE CHUNK:MUI-WINDOWLAYOUT ColumnGroup(2), Label( "_Mode,_Modus" ), Cycle( "m", "Bouncing Point|Wusel|Random,Springender Punkt|Wusel|Zufall" ), Label( "Wusel _lenght,Wusel_l nge" ), Slider( "l", 1, 20 ), Label("_Sound,To_neffekt"), HGroup, CheckMark( "s,n" ), HVSpace, End, Diese beiden Chunks aus CrazyPixel/gadget zeigen wohl alle Problemf die mir spontan einfallen. Da es in der Gadgetdatei keine Texte gibt, die sich nicht irgendwie auf die Bildschirmausgabe beziehen, sind alle Textangaben (erkennbar an den "-Zeichen) vom Locale-Chunk betroffen. Leser, die bis jetzt noch keinen CHUNK:MUI-WINDOWLAYOUT vor Augen hatten, brauchen sich den ja nicht anzusehen, erst nachdem sie die MUI-Kapitel gelesen haben. Wie man problemlos erkennen kann, hat jede Textangabe ein , in der Mitte. Dieses ist auch echt wichtig, da die Kommas die Sprachen voneinander trennen. Hier sind die linken Teile (also die 1. Sprache) englisch, und die rechten Teile (2. Sprache) deutsch. Also sieht der passende CHUNK:LOCALE so aus: CHUNK:LOCALE english,deutsch Weitere Sprachen k nnten folgen, dann m ssen aber auch alle Texte dement- sprechend mehr Kommas haben. Madhouse geht nun folgenderma en vor: - Wenn am Programmstart des MadhouseConfigEd bereits festgestellt wurde, dies kein OS 2.1-oder-h her-Amiga ist, wird ab sofort "english" als die voreingestellte Sprache angesehen; sonst die Sprache, die man im Locale-Editor der Workbench eingestellt hat (also z.B. "deutsch"). - Bevor nun ein BlankerPrefs-Fenster ge ffnet wird, wird die zugeh gadget-Datei nach dem CHUNK:LOCALE durchsucht (Ihr glaubt gar nicht, was das arme Ding alles mitmachen mu ...). Ist der nicht da, werden die Texte innerhalb der Anf hrungszeichen einfach ins Fenster bernommen, und diese Aufstellung hier hat ein Ende. Ist er aber da, wird nachgesehen, ob die Zeile mit den Sprachennamen die eingestellte Sprache (also f r OS 2.0 "english") beinhaltet, und wenn ja, nach dem wievielten Komma. Wenn nicht, wird die Sprache verwendet, die zuerst aufgef hrt wird (SOLLTE "english" sein). - Trifft nun Madhouse beim Aufbau der Gadgets auf Texte, also auf etwas das mit " anf ngt, so werden einfach dementsprechend viele Kommas sprungen, je nachdem, an welcher Stelle die ausgew hlte Sprache stand. Das Ergebnis wird weitergeleitet. Wie oben im GADGET-Chunk ersichtlich ist, hat bei Cyclegadgets das Komma eine h here Priorit t als das Trennzeichen |. Es wird also nicht jeder einzelne Cycleeintrag umgesetzt, sondern der gesamte Text. Au erdem sind r MUI-Programmierer - auch die Tastaturbelegungen als Texte anzusehen. Diese sind also auch lokalisiert, f r den Fall, da ein deutsches Wort keinen Buchstaben des englischen Wortes enth lt. Dementsprechend k die Buchstaben in den Gadgettexten anders unterstrichen werden, und die Gadgettasten k nnen unterschiedlich sein, wie bei "_Sound,To_neffekt". Wenn sich jedoch die Gadgettexte oder Tasten nicht unterscheiden, mu nicht extra "_Level,_Level" oder "l,l" geschrieben werden, "_Level" oder "l" reicht aus. Wenn Madhouse n mlich kein Komma findet, wird die Locale einfach nicht beachtet. Der LOCALE-Chunk selbst mu die Sprachennamen in Kleinschrift enthalten, und zwar in der Sprache auf die sie sich beziehen. Alles klar? N Was ich meine, ist, da man fran ais anstatt von franz sisch schreiben Hoffentlich ist der Locale-Chunk nun nicht zu einem der schwersten ge- worden. Es gibt da halt soviele Sonderf lle, OS 2.0 oder dr ber, ver- wendet oder nicht, vorn oder hinten, ... Aber das Beispiel hat doch alles klar gemacht, oder? Nat rlich, Carsten! Na prima, dann kann ich ja wieder beruhigt einschlafen. @endnode @node p_blankerinfo "CHUNK:BLANKERINFO" Dieser Chunk wird nicht f r das BlankerPrefs-Fenster ben tigt, sondern er wird von Madhouse w hrend des Verzeichnisbaum-Lesens gelesen. Er enth lt allgemeine Infos zum Blanker. Einige Daten werden nur vom MUI- Programmteil ausgewertet, aber bitte trotzdem immer alles ausf llen! @{B}EXTREM WICHTIG: Madhouse schaut sich die Daten in diesem Chunk NUR beim Lesen des Verzeichnisses (Path-Gadget benutzen) an. Das hei t, da eine nderung an diesen Werten nur dann eine Auswirkung auf Madhouse und den Blanker hat, wenn das Blankers-Verzeichnis neu gelesen wird. Bis dies nicht geschieht, arbeitet Madhouse mit den alten CPU-Usage und Stack-Werten. @{UB} CHUNK:BLANKERINFO Version CPU-usage Stack Name = Der Name des Autors. Version = Die Versionsnummer des Blankers. F ngt ab 1 an und wird dann ganzzahlig heraufgez hlt. 1.4 ist also falsch; 3, 6, 8008743 gehen aber. CPU-Usage = kann 1 oder 0 sein. Wenn "CPU active:" auf "only simple Blan- gers" gestellt ist, mu Madhouse wissen, ob der Blanker die CPU stark (1) oder fast gar nicht (0) beansprucht. 1/3 Belastung w rde ich noch zu 1 z hlen! Den ganzen CPU-Krams habe ich schon in @{"Advanced Options",link adv_op} erkl rt. Entscheidet selbst, ob Ihr neben Eurem Blanker einen Raytracer laufen lassen w rdet... Die CPU-Belastung kann mit einem entsprechenden Tool gemessen werden. Stack = h ngt von Eurer Programmierweise und dem Compiler ab. Zuerst sollte man es mit 5000 probieren und den Blanker gr ndlich austesten. Bei Problemen, die sich in Form von Abst ern sollten, einfach mehr probieren. Eventuell legt der Compiler (in C kann man das mit static bestimmen) alle Daten des Programms auf den Stack, dann kann man schnell die ben tigte Menge Speicherplatz berschlagen. Wenn sich Rekursionen im Programm befinden, sollte der Stack ebenfalls gro gig bemessen sein. (Hi Einsteiger: wer nicht wei , was Rekursionen sind, der hat auch keine im Programm!) @endnode @node p_bevelboxes "CHUNK:BEVELBOXES" Was ist plastisch, dreidimensional, sieht aus wie ein Button und ist (fast) v llig nutzlos?! - Bevelboxen! Bevelboxes sind die Umrandungen, die mehrere Gadgets zu einer Gruppe zu- sammenfassen. Im nicht-MUI-Fenster des Stars-Blankers kann man sie gut er- kennen. (Kleiner Tip: wer sich die BlankerPrefs-Fenster ansehen will, die von Madhouse erzeugt werden, wenn MUI nicht vorhanden ist, der kann - entweder die betreffende gadget-Datei um einen MUI-WINDOWLAYOUT-Chunk rmer machen oder - den ConfigEd mittels Use oder Save beenden, alle anderen MUI-Anwen- dungen beenden, mit "avail flush" in der Shell die muimaster.library aus dem Speicher r umen und diese Library umbenennen. Dann kann der ConfigEd sie nicht mehr finden, wenn er aufgerufen wird, und ffnet von nun an auch die normalen BlankerPrefs-Fenster.) CHUNK:BEVELBOXES Menge x,y,w,h [x,y,w,h] [x,y,w,h] [...] Menge = Die Anzahl der Bevelboxes. x = X-Position der Box. y = Y-Position der Box. w = Breite der Box. h = H he der Box. Hinter dem Chunk-Header folgt die Anzahl der Boxen. Dann dieselbe Anzahl Zeilen, jede Zeile definiert eine Box. @endnode @node p_texts "CHUNK:TEXTS" Der Text-Chunk erlaubt das Schreiben in die BlankerPrefs-Fenster. So nnen Texte erzeugt werden, die nicht direkt zu einem Gadget geh sondern frei in der Gegend positioniert werden k nnen. CHUNK:TEXTS Menge Farbe,x,y,Text [Farbe,x,y,Text] [Farbe,x,y,Text] [...] Menge = Die Anzahl der Texte. Farbe = Die Farbe des Textes (am besten nur 1 - 3). x = X-Position des Textes. y = Y-Position des Textes. Text = Der Text selbst. Bitte ohne Anf hrungszeichen. Ein solcher Text-Chunk ist ebenfalls im Stars-Blanker-"gadget"-file zu finden. Der Aufbau des Chunks hnelt dem der Bevelboxes, erst die Anzahl der Texte und dann genausoviel Zeilen darunter, jede Zeile spezifiziert einen Text. @endnode ## ------------------------------------------------------------------- @node pm_exp "Madhouse-MUI f r Leute, die sich schon auskennen." In diesem Kapitel werden nur die Unterschiede zwischen dem C-Makro- Headerfile "libraries/mui.h" und dem Chunk MUI-WINDWLAYOUT besprochen. Eigentlich sieht so eine Deklaration in der gadget-Datei genauso aus wie im C-Quelltext. (Bitte mal in einer gadget-Datei nachsehen!) Der Chunk MUI-WINDOWLAYOUT enth lt jedoch nur den Auszug einer MUI- Applikationsdeklaration, wo der Fensterinhalt erstellt wird. Madhouse kennt die Gruppentypen HGroup, VGroup sowie ColumnGroup( Anzahl der Spal- ten). Die Gadgets werden deklariert, indem man den Gadget-Typ zwischen ein Group,...End, schreibt und in Klammern die n tigen Parameter gibt (siehe @{"Gadget-Beschreibungen",link pm_gadgets}). Die Gruppen erhalten einen Titel, indem man diesen mit in die Gruppen- deklaration schreibt: VGroup( "Laber" ), bzw. HGroup( "Bla" ), oder ColumnGroup( "S lz", 2 ). Jede Gruppen- oder Gadgetdeklaration wird in eine Zeile geschrieben, immer von einem Komma gefolgt. Auch die letzte Zeile mu mit einem Komma abgeschlossen werden. Soll man einen Buchstaben angeben, der zur Tastatursteuerung von Gadgets benutzt werden soll, so mu dieser in Anf hrungszeichen eingeschlossen sein und nicht in Hochkommas, wie in C sonst blich. Diese Beschreibung reicht nat rlich noch nicht allein aus, um ein MUI- BlankerPrefs-Fenster zu erzeugen. Deshalb solltet Ihr noch die beiden unteren Kapitel (Gadgets, Gruppen) lesen. @endnode @node pm_start "MUI von Null auf Hundert f r MUI-Greenhorns." Damit Ihr die Erstellung einer MUI-Oberfl che schafft, mu ich Euer Hirn erstmal etwas durchsch tteln. Denn aus dem normalen Programmiereralltag seid Ihr absolute und pixelgenaue Positionierung von Gadgets und anderen grafischen Dingen gewohnt. Und jetzt kommt da einer daher, der Euch er- ren will, wie man eine komplette Oberfl che ganz ohne Koordinaten aufbaut. Nachdem ich Euch darauf hingewiesen habe, was Euch gleich er- wartet, kommt jetzt Psycho-Trick Nummer 1: Hier seht Ihr eine stilisierte Oberfl +--+----------------------------------------+--+--+ | | Fenstertitel | | | +--+----------------------------------------+--+--+ | Button 1 | +-------------------------------------------------+ | Button 2 | +-------------------------------------------------+ | Button 3 | +-------------------------------------------------+ | Button 4 | +-------------------------------------------------+ Beschreibt einfach verbal, was Ihr seht. Wie sind die vier Kn pfe in diesem Fenster angeordet? Na klar: untereinander. Oder anders ausgedr ckt: verti- Mit diesem kleinen Beispiel wird schon einmal deutlich, wie man Gadgets ohne Angabe von Positionen anordnen lassen kann. Man sagt MUI: Die Gadgets kommen untereinander. Au erdem sagt man MUI, was die Gadgets sind, also blichen Beschreibungen (Cyclegadget, was sind die Cycleeintr ge, was ist der Wertebereich eines Sliders u.s.w.). Daraus kann man sich ja schon ableiten, was wohl die zweite Anordnungsform sein wird: horizontal, also nebeneinander. Diese Anordnungsformen werde ich demn chst als "Gruppen" bezeichnen. Wir h tten da also horizontale und vertikale Gruppen. Aber das reicht ja noch lange nicht. Schlie lich sind Oberf lche meist viel komplizierter. Deshalb gibt es ein weiteres Feature: neben normalen Gadgets k nnen die Gruppen noch weitere Gruppen enthalten. Wie sieht also das oben dargestellte Fenster aus, wenn wir Anstelle von Button 3 eine horizontale Gruppe mit zwei Buttons setzen? Das solltet Ihr Euch jetzt mal auf Papier aufzeichen. Die L sung ist folgende: @{" ",link pm_solv}. rlich k nnen die Untergruppen noch Unteruntergruppen enthalten, so geht das dann weiter bis in alle Ewigkeit. Damit kann man dann schon eine Menge anstellen. In der Regel arbeitet man aber nicht nur mit Buttons, sondern viel mehr mit allen anderen Gadgettypen. Und die anderen Gadgettypen bestehen nicht nur aus dem Gadget selbst, son- dern auch aus dem Text davor, der das Gadget beschreibt. Dieser Text, der z.B. dem "Blanker wechseln/Exchange Blanker"-Checkmark erst seinen Na- men gibt, nennt man Label. r viele Gadgets kennt Madhouse eine Kurzform, die nicht nur das Gadget selbst, sondern auch das entsprechende Label davor erzeugt. Diese Kurz- formen verwendet man aber in der Regel sehr selten. Der Grund daf r ist, da alle Gadgets verschiedene Breiten und Ausdehnungs- glichkeiten haben, und da MUI die Gadgets von z.B. einer horizontalen Gruppe immer zur Mitte der Gruppe zentriert. Will man drei Slider einander erzeugen, die ja wahrscheinlich mit drei unterschiedlich langen Labels beschriftet werden, so gleicht keine linke Sliderkante der anderen. Man hat den Eindruck, da die Gadgets wild umherfliegen. Um die Oberf chen also sch ner zu machen, bietet MUI neben den horizon- talen und den vertikalen Gruppen noch die Spalten- bzw. die Column- Gruppen an. Wie hat man sich das vorzustellen? Eine Column-Gruppe steht nicht einfach so da und wird von oben nach unten gef llt, sondern sie hat eine Spaltenanzahl. Eine Column-Gruppe hat eine Struktur wie Karo- Papier, die K stchen werden von links nach rechts ausgef llt. Wenn die Spaltenanzahl erreicht ist, erzeugt die Column-Gruppe die n chste Zeile. Hier kommt ein Fenster mit einer Column-Gruppe mit zwei Spalten. Dieser Column-Gruppe wurden folgende Objekte zugeordnet: ein Label, ein Slider, ein Label, ein Slider, ein Label, ein Cycle-Gadget. +--+----------------------------------------+--+--+ | | Fenstertitel | | | +--+----------------------------------------+--+--+ | Label 1 | Slider | +-------------------------------------------------+ | Label 2 | Slider | +-------------------------------------------------+ | Label 3 | Cycle | +-------------------------------------------------+ Aber wie w rde sowas denn nun eigentlich in der Gadget-Datei aussehen? Zuerst mal der ungef hre MUI-CHUNK f r das erste Beispiel (eine einfache horizontale Gruppe mit vier Buttons): CHUNK:MUI-WINDOWLAYOUT VGroup, Button1, Button2, Button3, Button4, Hier werden einer vertikalen Gruppe (VGroup) vier Buttons zugeordnet. Das End "schlie t" diese Gruppe. Hinter jeder Zeile steht ein Komma, trotzdem darf man diese Ausdr cke nicht in einer Zeile zusammenfassen. Die zugeordneten Buttons r ckt man ein paar Zeichen ein, damit klar wird, da die Buttons zu dieser Gruppe geh ren. Man sagt auch: "Die Buttons sind Kinder der VGroup." Mit der VGroup (oder HGroup, falls die Gadgets nebeneinander geh und dem End verh lt es sich wie mit den Klammern in einem Text, so geh einer Gruppe immer das End, was in derselben Spalte steht. Madhouse liest das aber nicht an der Spaltennummer ab, sondern macht es anders (was ich hier aber nicht auch noch erk ren will). Deshalb mu man nichts einr cken, aber es ist doch bedeutend bersichtlicher. Und was ist nun mit der Column-Gruppe von eben? Da kommt sie: CHUNK:MUI-WINDOWLAYOUT ColumnGroup( 2 ), Label( "_Label 1" ), Slider( "l", 1, 10 ), Label( "L_abel 2" ), Slider( "a", -5, 20 ), Label( "La_bel 3" ), Cycle( "b", "Erster Eintrag|Zweiter Eintrag|Dritter Eintrag" ), Das ist schon viel Stoff, oder? Nach dem Chunk-Header "CHUNK:MUI-WINDOWLAYOUT", der Madhouse sagt, da hier die MUI-Beschrei- bung losgeht, folgt die Column-Gruppe mit den zwei Spalten, wie in der Skizze oben. Die folgenden Kinder der Gruppe werden von links nach rechts und von oben nach unten in die Spaltengruppe eingef gt. Man sollte darauf achten, da die Spaltenzahl Teiler der Anzahl der Kinder einer Column- Gruppe ist. Anders ausgedr ckt: wir haben sechs Kinder f r eine Gruppe mit zwei Spalten. 6 durch 2 geht glatt auf, 7 durch 2 z.B. nicht. Eine Column- Gruppe mu mlich immer bis in die letzte Spalte aufgef llt sein. Wenn einem das nicht pa t, behilft man sich anders, aber dazu sp Oben k nnen wir noch sehen, wie man ein Label erstellt. (Dieses Beispiel nnte man schon so wie es dasteht in eine Gadget-Datei schreiben.) Also, in die Anf hrungszeichen kommt der Text, der dann in das betreffende stchen" der MUI-Gruppe eingef gt wird. In diesem Text kann ein Under- score ("_") vorkommen, der angibt, da das nachfolgende Zeichen unter- strichen wird. Das ist auch n tig, damit der Benutzer wei , mit welcher Taste er ein Gadget steuern kann. MUI ist n mlich extrem tastaturfreundlich. Der nachfolgenden "Deklaration", ein Slider, wird schon als erstes Argu- ment der Buchstabe bergeben, mit dem der Slider gesteuert wird. Diese Buchstaben sind immer klein zu schreiben. Dann kommen Minimal- und Maximalwert des Sliders, also reicht der erste Slider von 1 bis 10. Nun wird der n chste Slider beschriftet. Er hat den Buchstaben "a", und sein Wertebreich geht von -5 bis 20. Jetzt kommt noch das dritte Label, Hotkey "b". Dann kommt etwas Neues: die Deklaration eines Cycle-Gadgets. Wie auch beim Slider wird zuerst der Hotkey angegeben, dann folgen die Eintr ge des Cycle-Gadgets, getrennt durch "|". Wo wir gerade bei den Hotkeys, also den Tastatursteuerungsbuchstaben f Gadgets, sind: Diese Hotkeys d rfen nur einmal vorkommen. "Verbotene" Buchstaben sind o, t und c: Damit werden schon die Gadgets am unteren Rand des BlankerPrefs-Fensters gesteuert. War nicht vorhin davon die Rede, da man die Gruppen schachteln kann? Wann ben tigt man denn sowas? Sicherlich habt Ihr gemerkt, da MUI die Gadgets nicht nur automatisch, sondern auch dynamisch anordnet. So ziemlich jedes MUI-Fenster hat ein en-Gadget, und die Gadgets passen sich automatisch der neuen Fenster- e an, nachdem man es benutzt hat. Viele MUI-Fenster lassen sich nur in die Breite ziehen, die vertikale t sich weniger oft ver ndern (an einigen BlankerPrefs-Fenstern ausprobieren). Warum eigentlich? Nun, jedes MUI-Objekt (also vor allem die Gadgets, die Gruppen auch, aber von denen reden wir jetzt lieber nicht auch noch) hat eine minimale und maximale H he und Breite. Ein Slider, ein String- gadget, ein Cyclegadget und noch ein paar andere Sachen haben eine feste he. Klar, ein horizontaler Slider kann ja nur breiter werden, w rde er her, w rde das komisch aussehen. Bei vertikalen Slidern, die sich von oben nach unten slidern lassen, ist es umgekehrt. Listen haben aber sowie horizontale als auch vertikale Vergr erungsfrei- heit. Will man mehr von ihnen sehen, zieht man das Fenster einfach auf. Checkmarks stehen als Objekt da und lassen sich nicht gr er und kleiner machen. Also lassen sich viele MUI-Fenster nur horizontal vergr ern, weil die meisten Gadgets vertikal beschr nkt sind. Wir hatten aber eigentlich gerade das Problem f r die L sung gesucht, bei der man die Gruppen schachtelt. Nun stellt Euch mal vor, im letzten Bei- spiel w rde man das Cycle-Gadget durch ein Checkmark-Gadget ersetzen. Die beiden Slider w rden ihre Minimalbreite bekommen (beim Versuch, sich ngenm ig an das kleine Checkmark-Gadget anzupassen), und das Fenster re jetzt gar nicht mehr vergr erbar. Also machen wir das Checkmark seitlich ausziehbar. Das geht aber nicht. Also ersetzen wir das Checkmark durch eine horizontale Gruppe, die ein Checkmark und einen Slider enth lt. Nun w re das Fenster wieder horizontal vergr erbar, weil die ColumnGruppe wieder vergr erbar wurde, weil ihre Kinder (die Slider und die HGroup) vergr erbar sind. Die HGroup wurde brigens vergr erbar, weil EINS ihrer Kinder (n mlich der Slider) vergr erbar ist. Die Labels sind nicht vergr erbar. Genau m te es also hei Die Column-Gruppe ist horizontal vergr erbar, weil mindestens in einer Spalte alle Kinder der Gruppe vergr erbar sind. Nun w rden aber alle MUI-Applikationen h chst seltsam aussehen, wenn man immer Sliders als F llstoff verwenden w rde. Deshalb gibt es ein Objekt, das nach nichts aussieht und das auch nichts kann, das aber in alle Rich- tungen ausziehbar ist. Wenn n tig, bis nach Tokio. Dieses Objekt hei t "HVSpace", also w rtlich bersetzt, horizontaler und vertikaler Raum. Also greifen wir wieder das letzte Beispiel aus. So w rde die Skizze aus- sehen, wenn man das Cycle-Gadget durch eine horizontale Gruppe mit Checkmark und HVSpace ersetzen w +--+------------------------------------------+--+--+ | | Fenstertitel | | | +--+------------------------------------------+--+--+ | (Label 1) | (Slider---------------------------) | +---------------------------------------------------+ | (Label 2) | (Slider---------------------------) | +---------------------------------------------------+ | (Label 3) | (Checkmark) | (HVSpace------------) | +---------------------------------------------------+ Die Objekte haben jetzt Klammern und Spiegelstriche bekommen, um anzudeu- ten, wie ihre Ausdehungsm glichkeiten sind. Und wie sieht der MUI-WINDOWLAYOUT-Chunk aus? Voil (Anm. des Autors: 4 Jahre Franz sischunterricht hatten wenig zur Folge. Aber den acent von voil kann ich schon richtigherum setzen, ohne im dictionnaire nachschlagen zu m ssen.) CHUNK:MUI-WINDOWLAYOUT ColumnGroup(2), Label( "_Label 1" ), Slider( "s", 1, 10 ), Label( "L_abel 2" ), Slider( "a", -5, 20 ), Label( "La_bel 3" ), HGroup, CheckMark( "b" ), HVSpace, End, Mit diesem Beispiel sollte nun der MUI-Groschen gefallen sein. Mit HV- Space k nnen auch ColumnGruppen aufgef llt werden, bei denen man nicht jede Spalte einer Zeile ben tigt. Eine ausgiebige Lekt re der mitgelieferten gadget-Dateien ist sicher auch hilfreich, falls man mit MUI einen bestimmten Effekt erzeugen will, dessen technische L sung einem nicht einf rlich war das jetzt noch nicht die gesamte MUI-Anleitung, aber erst- mal das Grundwissen zum Layout-Prozess. Die einzelnen Gadgettypen und noch eine Spezialit t bei den Boxen werden in den n chsten Kapiteln beschrieben. Wie auch das Programmieren, kann das Erzeugen von MUI-Windowlayout- Chunks nicht "auf dem Trockenen" erlernt werden. Etwas bung geh auch dazu. Wer das Grundprinzip verstanden hat, der hat es nun auch schon leichter, in die MUI-Programmierung von richtigen Programmen einzusteigen. Allerdings schreibt man dann diese Group-Geschichten in den Programmcode und l t sie von einem waschechten Compiler interpretieren, nicht von einem kleinen Programm namens MadhouseConfigEd. Wo da der Unterschied liegt? Nun, ein Compiler entsteht in mehreren Mannjahren Arbeit, der Madhouse-Programmteil zum Lesen des MUI-WINDOWLAYOUT-Chunks entstand in einer halben Woche. Deshalb sei es mir verziehen, wenn ich a) nicht jedes Feature in den Interpreter eingebaut habe. Es lassen sich keine Page-Gruppen erzeugen, die Ausdehnungs-Gewichte der Objekte stehen fest auf 100, und es gibt auch keine CustomClasses (was wohl meilenweit bertrieben w re) und manche Spezialgadgets fehlen auch. Die wichtigsten Dinge k nnen aber problemlos erzeugt werden, deshalb sehen die Blanker- Prefs-Fenster auch genauso gut aus wie "richtige" MUI-Appliationen wie Madhouse und alle anderen. b) die Fehler in einer gadget-Datei nicht peinlich genau abfrage. Madhouse ist mir zwar infolge von solchen Fehlern noch nie abgest rzt, und das wird es sicher auch nicht. Aber es gibt nicht zu jedem Fehler eine Fehlermeldung, denn da h tte ich ja fast alle der 260 Fehler, die mein C-Compiler melden kann, auch auf die gadget-Dateien bertragen m ssen. Aufmerksam wird man auf die Fehler sowieso, und finden tut man sie auch schnell, denn der MUI-Chunk ist ja immer nur ein paar Zeilen lang. brigens arbeitet auch Vionas EGS auf dem Boxenprinzip, die Gadgets werden hnlich wie bei MUI angeordnet. EGS wurde auf dem Amiga durch die vielen Grafikkarten, mit denen es ausgeliefert wird, bekannt. Deshalb gibt es wohl auch kaum EGS-Anwendungen, die nichts mit Grafik zu tun haben. @endnode @node pm_solv "Die L sung" +--+----------------------------------------+--+--+ | | Fenstertitel | | | +--+----------------------------------------+--+--+ | Button 1 | +-------------------------------------------------+ | Button 2 | +-------------------------------------------------+ | Button A | Button B | +-------------------------------------------------+ | Button 4 | +-------------------------------------------------+ @endnode @node pm_groups "Die Gruppen" rlich erkl re ich hier nicht das gesamte Boxenprinzip erneut. Das steht ja schon alles im Greenhorn-Kapitel. @{B}HGroup und HGroup( "Gruppentitel" )@{UB} Die HGroup, die ihre Kinder ja bereinander anordnet, kann auch umrahmt werden, und wird damit sichtbar. In diesem Rahmen wird dann ein Gruppen- titel dargestellt, der die Gruppe sozusagen berschreibt. Will man so ein Ding erzeugen, benutzt man die HGroup so wie es in der berschrift steht. Dasselbe geht auch mit VGroups. @{B}ColumnGroup( x ) und ColumnGroup( "Gruppentitel", x )@{UB} x steht nach wie vor f r die Anzahl der Spalten. Wie auch die anderen Gruppen kann die ColumnGroup einen Titel bekommen. @endnode @node pm_gadgets "Die Gadgets" @{B}Einige Standard-Bezeichner in diesem Kapitel@{UB} - @{I}Taste@{UI} enth lt einen Kleinbuchstaben, der angibt, mit welcher Taste auf dem Keyboard des Computers ein Objekt gesteuert werden kann. Beispiel: Slider( "a", 5, 10 ) erzeugt einen Slider, der mit der Taste A gesteuert wird. Die Tasten "o", "c" und "t" sind bereits f r die Standard- Gadgets am unteren Rand des BlankerPrefs-Fensters reserviert und k daher nicht benutzt werden. - @{I}Bezeichnung@{UI} steht f r einen Text, auf der linken Seite des betreffenden Gadgets angezeigt werden soll. Dieser Text soll das Gadget n her erl utern. Beispiel: LabelCycle( "Color _selection", "s", "Red|Green|Blue" ) w ein Cycle-Gadget herstellen, auf dessen linker Seite sich der Text "Color selection" befindet, bei dem der Buchstabe "s" unterstrichen wird. Das ist tig, damit der Benutzer wei dieses Cycle-Gadget mit dem Buchstaben "s" gesteuert wird. @{B}Slider( Taste, Minimalausschlag, Maximalausschlag )@{UB} erzeugt einen Slider. Minimal- und Maximalausschlag bezeichnen den Aktions- Radius des Sliders, inklusive dieser beiden Werte (d.h., da Minimalaus- schlag selbst ist auch noch anw hlbar ist). @{B}LabelSlider( Bezeichnung, Taste, Minimalausschlag, Maximalausschlag )@{UB} wie oben, jedoch zus tzlich mit einem Label auf der linken Seite. @{B}CheckMark( Taste )@{UB} stellt ein H kchengadget her. @{B}Cycle( Taste, Auswahlm glichkeiten )@{UB} stellt ein Cycle-Gadget mit mehreren Eintr gen her. "Auswahlm glichkeiten" ist eine Zeichenkette, die alle Eintr ge enth lt. Ein Beispiel daf "RGB|HSV|CMYK". Der Vertikalstrich "|" trennt die Eintr ge. MUI beginnt das hlen der Eintr ge (wie sich das f r einen Computer geh rt) mit Null, wenn also RGB der aktive Eintrag ist und der User auf "Test" klickt, steht eine "0" in der prefs-Datei. @{B}LabelCycle( Bezeichnung, Taste, Auswahlm glichkeiten )@{UB} wie oben, jedoch zus tzlich mit einem Label auf der linken Seite. @{B}String( Taste, L nge )@{UB} erzeugt ein String-Gadget. Es lassen sich maximal so viele Zeichen ein- geben, wie bei "L nge" angegeben. Wieder ist die Obergrenze f r eine Stringl nge 500, was dar ber geht wird automatisch auf 500 gesetzt. @{B}LabelString( Bezeichnung, Taste, L nge )@{UB} wie oben, jedoch zus tzlich mit einem Label auf der linken Seite. @{B}Label( Bezeichnung )@{UB} erlaubt eine bessere Plazierung der Objekte. Wenn Label und Objekt getrennt werden (macht man normalerweise so), dann schlie en die Gadget-Rahmen b ndig ab. Man ben tigt dann einen Gadgettyp ohne Label... am Anfang und dieses Label-Objekt. Bezeichnung ist diesmal alles, aus was das Objekt besteht. @{B}LLabel( Bezeichnung )@{UB} wie oben, jedoch wird dieses Label nicht rechts ausgerichtet, sondern links. Das ist praktisch, wenn man hinter einen Slider noch eine Angabe klemmen will. Sonst sollten alle Objekte links beschriftet werden, nur bei den CheckMarks bin ich mir da nicht so sicher (da macht auch eine Beschriftung auf der rechten Seite Sinn). Ein Beispiel f r linksb ndige Labels findet sich in der gadget-Datei von Waves. @{B}HVSpace@{UB} der ber hmte Platzhalter, wie viele andere Dinge schon bekannt aus dem Vorkapitel. @{B}HBar@{UB} Eine sehr elegante Sache, die die Gruppen-Rahmen manchmal ersetzen kann: dieses Objekt zeichnet einen waagerechten Strich an seiner Position, und sollte nur in horizontalen Gruppen zur Trennung von Funktionen benutzt werden. @{B}VBar@{UB} wie oben, jedoch in der vertikalen Ausf hrung. Eine VBar l t sich gut im BlankerPrefs-Fenster von Stars beobachten. @endnode @node pm_mpo "Der CHUNK:MUI-PREFSORDER" "Wie kann MUI nur mit einem Chunk auskommen?", werden viele schon gefragt haben. So ganz geht das doch nicht. Aber jetzt wieder zuerst ein Problem. Ganz oben, in der Erkl rung wie man einen Blanker zu schreiben hat, schrieb ich, da Madhouse die Einstellungen der Gadgets in der Reihenfolge in die prefs-Datei abspeichert, in der die Gadgets im CHUNK:GADGETS angegeben wur- den. Und im CHUNK:MUI-WINDOWLAYOUT? Da ist es genauso. Allerdings haben wir da ein gaaaanz kleines Problem: Man kann mit diesem MUI-Chunk nicht ein Gadget in die obere Fensterecke legen und dann seine Einstellung zuletzt auslesen wollen. Nat rlich k nnte man jetzt den Programmtext ndern, und mir f llt gerade ein, wie sinnlos diese Funktion ist, aber man kann eine bestimmte Funktion von Madhouse benutzen, n mlich den CHUNK:MUI-PREFSORDER. In diesem Chunk wird die Reihenfolge angegeben, mit der die Einstellungen in die prefs-Datei geschrieben werden. Bei Waves und Stars habe ich diesen Chunk ben tigt. Auch Note enth lt einen. Dazu mu man nun zuerst jedem Gadget einen internen Namen geben, zum Bei- spiel so: CHUNK:MUI-WINDOWLAYOUT VGroup, LLabel( "Ein Ausschnitt aus der Stars-gadget-Datei." ), ColumnGroup( 2 ), Label( "_Maximum" ), Maximum = Slider( "m", 1, 8 ), Label( "M_inimum" ), Minimum = Slider( "i", -7, 1 ), Label( "C_anges" ), Changes = Slider( "a", 0, 15 ), Label( "_Start" ), Start = Slider( "s", -7, 8 ), End, Normalerweise w rde die prefs-Datei so aussehen: Wert von Maximum Wert von Minimum Wert von Changes Wert von Start Duration-Zeit in Minuten Pfad auf das Verzeichnis des Blankers Und jetzt kommts: schreibt man noch CHUNK:MUI-PREFSORDER Changes, Start, Minimum, Maximum dann sieht die prefs-Datei schon ganz anders aus: Wert von Changes Wert von Start Wert von Minimum Wert von Maximum Duration-Zeit in Minuten Pfad auf das Verzeichnis des Blankers Naja, sowas braucht man wohl sehr selten bis gar nicht... Wichtig ist aber noch, da als "interne Bezeichner" nur ganz gew hnliche Buchstaben in Frage kommen, nicht aber Zahlen und andere Spezialit @endnode @node addon "Anhang" @{"A Arrrggh: Bekannte Probleme ",link problems} @{"B Die Autoren und das: Copyright ",link authors} @{B}@{"C Madhouse ist toll: Registrieren leicht gemacht. ",link registration}@{UB} @{"D Die Revolution: MUI ",link mui_info} @{"E Nutzlos : alle hier verwendeten Smileys",link smileys} @endnode @node problems "Bekannte Probleme" @{B}Probleme - Kapitel I: Probleme, die von einer Programmiersprache namens AMOS ( ber 43.655 versch. Befehle...) erzeugt werden:@{UB} @{U}Probleme mit VGA-Monitoren@{UU} Genialerweise ffnen AMOS-Programme keinen normalen Intuition-Screen. Wer einen VGA-Monitor ohne ScanDoubler o. . sein eigen nennt, der kann zwar die Blanker, die von mir in C++ geschrieben wurden, mittels eines Screen-Promoters umpatchen; aber die AMOS-Blanker von Aicke m ssen hier klein beigeben. In diesem Fall hat Madhouse nur sechs Blankmodes, sorry. Falls tats chlich mal die AMOS-AGA-Version erscheinen sollte, f r die auch das ffnen von normalen Screens versprochen wurde, wird Aicke alle AMOS-Blanker darauf anpassen. Falls Aicke die Programmiersprache wechseln sollte (ist noch unwahrscheinlicher), h ttet Ihr und ich weniger Probleme. Madhouse mu mlich extra abgestimmt werden, damit AMOS die erzeugten Textdateien lesen kann. @{U}Probleme mit MousoMeter@{UU} MousoMeter macht leider ebenfalls Probleme mit AMOS-Programmen, was sich ert, da MousoMeter wie wild Kilometer z hlt. Das bricht jeden High- score. Der Grund ist wohl, da AMOS AMOS ist. (Anders kann ich mir das nicht erk ren.) Spitze, AMOS! Abhilfe: AMOS-Blanker inaktivieren. @{B}Probleme, die durch inkompatible Programme entstehen (auch AMOS..)@{UB} @{U}Probleme mit AMOS und Protracker (und vielleicht mit anderen Tracker-@{UU} @{U}Sound-Editoren, nicht aber mit MED)@{UU} Manche Programmierer wollen wohl die Grafikausgabe beschleunigen, indem sie einen Screen ffnen, der kein Intuition-Screen ist. Diesen k nnt Ihr nicht wie gew hnlich umschalten, au er wenn diese Programmierer die Tasten (und +m) selbst abfragen. Na ja, jedenfalls kann man die- ses Etwas nicht nach hinten bringen, indem man selbst einen Intui-Screen ffnet. Deshalb werden die Blanker FlyingToasters, Stars, FireWorks, Waves, Socher und Shuffle (die ich in C schrieb) HINTER AMOS und Protracker ange- zeigt. Die anderen Blanker, die Aicke in AMOS schrieb (paradox, oder?) nnen aber vor AMOS und Protracker angezeigt werden. Also d rfen nur diese Blanker bei Benutzung von AMOS und Protracker angew hlt sein. Weiterhin funktionieren mit obigen Programmen der Black Background und der Pa wortscreen nicht, aus demselben Grund. @{B}Probleme, die in Sondersituation 48d entstehen:@{UB} @{U}Probleme mit einer resetfesten Ram-Disk,@{UU} @{U}die als RAM: gemountet ist@{UU} Dieser Tip stammt von Aicke, und vielleicht bleibt er auch der einzige User, der gar keine nicht-resetfeste Ram-Disk hat, daf r eine reset- feste SD0: oder VD0:, die ber RAM: angesprochen wird. Wer also Madhouse bei jedem Systemstart automatisch aufrufen l (z.B. mit der WBStartup-Schublade) und wer ein Ger t namens RAM: hat welches nach einem Reset NICHT wieder leer ist, der hat ein Problem: Madhouse wird nach einem Reset beim Start schon die Schublade RAM:Madhouse_Storage vorfinden und denken, es w re 2x gestartet worden. Dieses Problem kann man nun umgehen, indem man VOR dem Start von Madhouse dieses Shell-Kommando ausf hren l t, indem man es z.B. in die S:User-Startup eintr delete >NIL: RAM:Madhouse_Storage ALL Beachtet bitte, da es nicht m glich ist, gar kein RAM:-Device zu haben. @endnode @node authors "Die Autoren und das Copyright." @{FG Highlight}@{B}Eine Art History-File: kleiner Geschichtsunterricht@{UB}@{FG Filltext} Wir brauchten neunzehn Monate, um Madhouse und die Blankmodes zu entwik- keln. Aicke hat fr her angefangen, weil mein Computer damals gerade in Reparatur war. So entstanden einige seiner Blankmodes fr her. Madhouse wurde von uns schon fr her erdacht, denn immer, wenn wir einen modularen Screenblanker in PD-Serien gesehen hatten, gefiel er uns nicht richtig. Wir hatten viele Ideen f r ein besseres Hauptprogramm, die gr tenteils in Madhouse verwirklicht wurden. Doch am rgerlichsten waren oft die Blankermodule, so kann man sie bei einigen Blankern gerade noch als Beispielprogramm durchgehen lassen (dabei waren die Dinger echt dazu gedacht, die Leute zu begeistern)... Jedenfalls k nnen wir die Urspr nge von Madhouse nicht mehr richtig nachvollziehen. Eine Kritzelei, die schon etwas aussieht wie das Hauptfenster befindet sich noch in meinem alten Deutschordner und hat das Datum 6.8.93. Damals hie meine Programmiersprache noch GFA-Basic. Im "Entwicklertagebuch" des Hauptprogramms kann ich aber den Beginn noch ablesen: am 25.1.94 entwarfen Aicke und ich das Design des Haupt- fensters. Der Name von Madhouse war zu dieser Zeit nicht Madhouse, sondern "BlackHole". Diesen Namen gab es aber schon. So hatte Aicke in den folgenden Wochen diverse Einf lle f r neue Namen. Am 26.2. konnten wir uns dann f r "Madhouse" entscheiden. Alternativen waren z.B "Joke- Box" oder "Monitor-Holidays". Wie jedes Programm hatte auch Madhouse viele Bugs. Fast zur Verzweiflung trieb mich ein ganz hartn ckiger, der Madhouse nach Bet tigung des Remove- Buttons zum Abst rzen brachte. Dabei st rzte der Computer genau (das konnte ich kontrollieren) beim Aufruf der exit()-Funktion ab, der ein Programm beendet. Nach mehreren Wochen fiel mir dann auf, da es an der Stackgr e von Madhouse lag... @{FG Highlight}@{B}Arbeitsteilung: Entwicklung beim Einen, Abst rze beim Anderen...@{UB}@{FG Filltext} (war umgekehrt nicht der Fall... AMOS als absturzfreie Sprache??!) Von Aicke stammen 62,5% der Blanker. Wahrscheinlich kann man an seinen Blankern und auch an den anderen Teilen Madhouses erkennen, da er ein echter Perfektionist ist. Das hat es einerseits nicht einfach gemacht, mit ihm zu arbeiten, aber es hat Madhouse oft entscheidend verbessert. So hat er in allen Dingen, die zu Madhouse geh ren, seine Spuren hinter- lassen: ob er nun f nf Pixel an der kleinen Diskette ge ndert hat, die im Ask-For-Disk-Fenster erscheint oder ob er eine gute Idee f r FireWorks hatte. Ideen hat er auch viele, so da er schon neue Blankmodes in Vor- bereitung hat. Die AMOS-Demo ist auch von ihm. Madhouse ist mein zweites C-Programm (eigentlich C++), das Erste waren die FlyingToasters. Von mir kommt auch die englische und deutsche Anlei- tung. In der Englischen werden viele Fehler sein, in der Deutschen viele Abweichungen vom Thema... (Leider seht Ihr nun gar nichts von der engl. Anleitung, weil die f r eine deutsche Zielgruppe nun doch nicht mehr n tig ist.) Da das Einsteigen in eine Sprache wie C recht schwierig ist, danke ich allen die durch ihre Quelltexte im PD-Bereich etwas Licht in das gro e Compilerdunkel brachten. An die seitenlangen Compilerfehler kann ich mich noch gut erinnern. Die C-Demo habe ich auch geschrieben, das war meine erste echte Konfrontation mit dem ANSI-C-DosLib-File-I/O. Zusammen haben wir einen Vorteil anderen Programmieren gegeb ber, die allein arbeiten: Wir haben verschiedene Computer. Damit kann man Programme besser auf Fehlerfreiheit testen, den die Betriebssysteme 2.0 / 3.0 reagieren bei Programmfehlern so gut wie immer unterschiedlich. @{FG Highlight}@{B}Blick in die Glaskugel@{UB}@{FG Filltext} In Zukunft werden hoffentlich neue Blanker erscheinen. Die m ssen dann nicht unbedingt von uns sein, denn mit der mitgelieferten Dokumentation (in dieser Anleitung) kann so ziemlich jeder selbst einen Blanker her- stellen. Eine Idee w re noch ein Sound-Teil, Madhouse k nnte Musik- Module abspielen w hrend die Blanker laufen. Meine wichtigste Planung r die Zukunft war das MUI-Interface f r Madhouse. Wie Ihr sicherlich schon gemerkt habt, haben die MUI-Funktionen schon den Sprung in diese Version geschafft. Wir haben schon eine Menge Ideen f r neue Blanker. Teilweise ist schon Grafik fertig. Auch manche vorhandenen Blanker sind noch Verbesserungs- hig. Falls es einen Geschwindigkeitszuwachs gibt (und das hoffe ich doch) werden die FlyingToasters mit Bobs arbeiten. Ein Aquarium w re auch langsam f llig, oder fangen wir doch lieber mit einer anderen Idee an? Madhouse ist Shareware, der Betrag ist 20 DM. Im Registrationskapitel (@{"Anhang C",link registration}) k nnt Ihr alles ber die Registration erfahren. Wenn Ihr einen Bug findet, bitte schreibt uns! Wenn jemand einen guten Blanker geschrieben hat, soll er/sie (?) ihn nicht nur f r sich behalten, sondern auch ver ffentlichen! Es w re wirklich super, wenn auch andere Programmierer unser System nutzen w rden. @{FG Highlight}@{B}Unser Input-Device: schreibt uns mal!@{UB}@{FG Filltext} Ihr k nnt uns Ideen, Grafiken und Code senden, dann versuchen wir, was draus zu machen. Wenn Ihr eine Antwort wollt, legt bitte genug Brief- marken bei (am besten deutsche oder internationale). Wer wei , wieviel da ankommt... (Wahrscheinlich gar nichts, sowas kennt man ja.) Wenn Ihr uns wegen Bugs schreibt, dann erkl rt bitte peinlich genau WAS passiert ist, WIE Ihr das geschafft habt und WELCHE anderen Sachen im Hintergrund liefen und welchen Computer Ihr benutzt. Desweiteren ben tigen wir eine genaue Beschreiben der Pflanzen im Computerraum. Am besten Ihr versucht es auch ohne Tools und mit Eurer Original- Workbench, bevor Ihr uns mit Back-Beschreibungen zudr hnt... Nat rlich sind wir auch froh, wenn wir Bugmeldungen erhalten, aber andere Dinge rden uns halt mehr freuen - verst ndlich, oder? Leider verf gen wir mangels Modem ber keine E-Mail-Adresse. Aicke Schulz Neudeckerweg 118 D-12355 Berlin Telefon: 030 (Berlin) / 664 48 22 Carsten Jahn Kuckucksruf 34 D-16761 Stolpe-S Vielen Dank f r den Brief! rlich d rfen auch die Credits, sprich Danksagungen nicht fehlen. Die Blanker CrazyPixel, DigitalClock, Drops, Glitter, Memory, Note, Skyline, SoftwareFailure, Thunder und Worldtime wurden mit der Programmiersprache AMOS entwickelt. Die Blanker FireWorks, FlyingToasters, Shuffle, Soccer, Stars und Waves sowie das Hauptprogramm wurden mit dem MaxonC++-Light 3 Compilerpaket erstellt und compiliert. Madhouse und alle dazugeh rigen Daten und Programme sind Copyright 1994-1995 Carsten Jahn und Aicke Schulz. Alle Rechte weltweit vorbehalten. @{"MagicUserInterface",link mui_info} wurde von Stefan Stuntz entwickelt, die Rechte daf liegen bei ihm. +---------------------------------------------------------------+ | Wer Madhouse verf lscht oder nachmacht, oder verf lschte oder | | nachgemachte Versionen in Umlauf bringt, wird mit Windows | nicht unter zehn Stunden bestraft. | +---------------------------------------------------------------+ rlich wird keinerlei Haftung f r Sch bernommen, die durch den Gebrauch von Madhouse entstehen / entstanden sind. r den Gebrauch von Windows haften wir erst recht nicht. Und w rend ich hier die Zeile 3591 der Anleitung schreibe, verabschiede ich mich und w nsche allen Amiga-Usern ein langes, sch nes Leben, tolle Programme, neue Blanker, einen Multiscanmonitor und uns allen das berleben des Amiga auf dem engen Markt der Hardwareplattformen. @{I}@{B}Tsch , bis zur n chsten Anleitung,@{UB} Euer Carsten.@{UI} @endnode ## Mu te wieder einer nachsehen, ob die Zeilennummer wirklich stimmt :-) @node registration "Registration" Seit eineinhalb Jahren haben wir Madhouse auf unseren Computern. Endlich ist es uns gelungen, es einigerma en fertigzustellen. Ein modulares System kann zwar gar nicht fertig sein, schlie lich k nnten noch hunderte von Blankern hinzukommen, aber die Hauptprogramme Madhouse und MadhouseConfigEd sind langsam ausgereift. Nun sollte es jedem Amiga-User zug nglich sein, und wir hoffen wenigstens auf ein kleines Feedback. Ohne das Keyfile, das jeder registrierte User von uns per Post erh lt, l sich Madhouse nicht dauerhaft benutzen. Ist es nicht vorhanden, werden die Einstellungen in ENV: und ENVARC: nicht beachtet, also mu nach jedem Start mindestens der Pfad zu den Blankern neu eingestellt werden. Nach der Registration erhaltet Ihr von uns eine Diskette, die eine Datei namens Madhouse.key enth lt. Diese solltet Ihr in Euer S: - Verzeichnis ko- pieren. Sonst kopiert Ihr die niemandem! Sie enth mlich Eure komplette Anschrift, die Ihr 1. nicht im Keyfile ndern solltet, sonst wird es nicht mehr erkannt, und die Euch 2. sofort entlarvt, wenn sie einmal der Falsche in die H nde kriegt. Um Euch registrieren zu lassen, ben tigt Ihr: - Das ausgef llte Registrationsformalur. Dieses k nnt Ihr einfach aus- drucken und leserlich ausf llen. - Den Betrag von @{B}20 DM@{UB}, soviel kostet das. Dieser Preis ist doch ugling-, Kleinkinder-, Jungliche-, Erwachsenen- und Seniorenfreundlich, oder? - Einen normalen Briefumschlag. Da steckt Ihr o.g. hinein. - Eine 1DM-Briefmarke. Die klebt Ihr auf o.g. drauf. - Einen Briefkasten in Eurer N he. Da steckt Ihr o.g. hinein. Mut geh brigens nicht dazu - Ich habe schon dreimal Geld f r solche Zwecke mit der Post verschickt, nach Deutschland, nach Holland und nach England, und immer hat es geklappt. Wer das aber will, der kann das Geld auch berweisen: Aicke Schulz Deutsche Bank, BLZ 100 700 00, Konto-Nr. 3565611 Bitte trotzdem das Formular ausf llen und an uns schicken! Als mordsm igen Bonus garantieren wir den ersten zwanzig Bestellern, da sie eine Diskette mit unserer Handschrift und Autogrammen erhalten! (Schlie lich lohnt es sich nicht, f r 0 oder 4 Disketten Aufkleber zu drucken...) Alles klar? Na, dann wollen wir mal den @{"Ausdruck starten" system "copy Registration_D.txt to PRT:"}. @endnode @node mui_info "Auch Madhouse benutzt das sagenhafte MUI." This application uses MUI - MagicUserInterface (c) Copyright 1993/94 by Stefan Stuntz MUI is a system to generate and maintain graphical user interfaces. With the aid of a preferences program, the user of an application has the ability to customize the outfit according to his personal taste. MUI is distributed as shareware. To obtain a complete package containing lots of examples and more information about registration please look for a file called "muiXXusr.lha" (XX means the latest version number) on your local bulletin boards or on public domain disks. If you want to register directly, feel free to send DM 30.- or US$ 20.- to Stefan Stuntz Eduard-Spranger-Stra 80935 M nchen GERMANY Stefan will uns damit sagen, da die Oberf che von Madhouse mit installier- tem MUI v llig frei von Euch gestaltet werden kann. Dem kann ich nur zu- stimmen. MUI geh rt zu den flexibelsten Programmen, die ich je gesehen habe. MUI ist kein normales Programm, was man f r einen bestimmten Zweck benutzt. Jede entsprechend programmierte Anwendung kann es verwenden, und dann profitiert der Anwender davon. In PD-Serien und Mailboxen findet man die aktuelle Version von MUI, so richtig toll ist aber nur die unter der oben genannten Adresse zu beziehende Vollversion, mit der man die Ein- stellungen dauerhaft speichern kann. Sonst sehen die MUI-Anwendungen nach jedem Reset wieder ganz normal aus. @endnode @node smileys "Alle in dieser Anleitung verwendeten Smileys" Neben dem Standard-Smiley :-) wurde der Einsatz weiterer Arten in dieser Anleitung n tig. Die m ssen nat rlich noch entsprechend gedeutet werden: ==) Smiley mit Darth-Vader-Helm. *-{:-) Smiley mit Bommelm tze (Inspiration aus der Winterzeit). ) Smiley mit Designerbrille (und Knollennase). :^) Smiley aus der isometrischen Perspektive. Allen Smiley-Fans empfehle ich stark das Archiv misc/misc/SmileyV3.lha aus dem AmiNet. @endnode